perm filename COMMON.MSG[COM,LSP] blob
sn#886319 filedate 1990-08-03 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00035 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00006 00002
C00007 00003 ∂13-Dec-88 1443 Common-Lisp-mailer foreign function
C00009 00004 ∂13-Dec-88 1707 Common-Lisp-mailer file loading query
C00014 00005 ∂13-Dec-88 2107 Common-Lisp-mailer Common Lisp for SUNS
C00016 00006 ∂14-Dec-88 0813 Common-Lisp-mailer RE: load defaults
C00020 00007 ∂14-Dec-88 0959 Common-Lisp-mailer RE: load defaults
C00022 00008 ∂14-Dec-88 1619 Common-Lisp-mailer Re: load defaults
C00025 00009 ∂15-Dec-88 1720 Common-Lisp-mailer WG16 document N31, "Working documents on CALLING MECHANISMS..."
C00026 00010 ∂15-Dec-88 1853 CL-Compiler-mailer dumping weird objects to compiled files
C00030 00011 ∂16-Dec-88 0123 Common-Lisp-mailer file loading query
C00032 00012 ∂16-Dec-88 0733 CL-Compiler-mailer Re: dumping weird objects to compiled files
C00035 00013 ∂16-Dec-88 0843 Common-Lisp-mailer Re: dumping weird objects to compiled files
C00038 00014 ∂16-Dec-88 1821 Common-Lisp-mailer file loading query
C00042 00015 ∂22-Dec-88 1219 Common-Lisp-mailer commonlisp types
C00049 00016 ∂27-Dec-88 0819 Common-Lisp-mailer Experiences porting applications from Symbolics
C00052 00017 ∂02-Jan-89 1238 Common-Lisp-mailer commonlisp types
C00056 00018 ∂03-Jan-89 0340 Common-Lisp-mailer commonlisp types
C00060 00019 ∂03-Jan-89 1714 Common-Lisp-mailer PROG1 as a function
C00063 00020 ∂04-Jan-89 0102 Common-Lisp-mailer commonlisp types
C00066 00021 ∂04-Jan-89 0537 Common-Lisp-mailer re: commonlisp types
C00068 00022 ∂04-Jan-89 0921 Common-Lisp-mailer PROG1 as a function meta-rules of CLtL
C00075 00023 ∂04-Jan-89 1054 Common-Lisp-mailer PROG1 as a function
C00078 00024 ∂04-Jan-89 1111 Common-Lisp-mailer PROG1 as a function
C00082 00025 ∂04-Jan-89 1131 Common-Lisp-mailer PROG1 as a function
C00085 00026 ∂04-Jan-89 1252 Common-Lisp-mailer PROG1 as a function meta-rules of CLtL
C00092 00027 ∂04-Jan-89 1328 Common-Lisp-mailer PROG1 as a function
C00096 00028 ∂04-Jan-89 1333 Common-Lisp-mailer PROG1 as a function
C00100 00029 ∂04-Jan-89 1337 Common-Lisp-mailer PROG1 as a function
C00103 00030 ∂04-Jan-89 1354 Common-Lisp-mailer Re: PROG1 as a function meta-rules of CLtL
C00108 00031 ∂04-Jan-89 1414 Common-Lisp-mailer PROG1 as a function
C00112 00032 ∂06-Jan-89 1346 Common-Lisp-mailer commonlisp types
C00116 00033 ∂06-Jan-89 1346 Common-Lisp-mailer commonlisp types
C00120 00034 ∂06-Jan-89 2112 Common-Lisp-mailer Re: commonlisp types
C00123 00035 ∂07-Jan-89 0054 Common-Lisp-mailer commonlisp types
C00127 ENDMK
C⊗;
∂13-Dec-88 1443 Common-Lisp-mailer foreign function
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 14:42:52 PST
Date: Tue, 13 Dec 88 12:54:23 PST
From: Thom Linden <baggins@ibm.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <881213.125423.baggins@IBM.com>
Subject: foreign function
Even though the bulk of participants in x3j13 are moving into the
"editorial" phase of the process, I see no reason why a new
subcommittee shouldn't be formed. It's probably unlikely that
anything would make it into the first release of the std but
it is reasonable for folks to begin work on next release items as with,
for example, some of the iteration committee activity. Another
example might be vol3 of CLOS. We shouldn't be pressed prematurely
into incorporating everything into the 1989 draft.
At the Jan meeting, someone should suggest this subcommittee be
formed and simply begin the discussion with those of similar interest.
∂13-Dec-88 1707 Common-Lisp-mailer file loading query
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 13 Dec 88 17:06:48 PST
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 13 Dec 88 20:05:13 EST
To: common-lisp@sail.stanford.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: file loading query
Date: Tue, 13 Dec 88 20:04:24 EST
Message-ID: <2131.598064664@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU
I have a problem with the way Common Lisp says pathname defaults should be
handled during load. I have a software system structured as a header file
FOO.LISP that loads various component files BAR1, BAR2, BAR3, etc. Some of
the component files may in turn load other components.
Now, I actually have several versions of this system, each living in its
own directory. Whenever I make a new version due to an experimental change
to one component, or to test out the code generated by a new compiler, I
put it in its own directory. The problem is, how do I get the calls to
LOAD that appear in FOO, and in the files loaded by FOO, to look in
whatever directory the header file FOO was loaded from?
The current definition of LOAD looks at *DEFAULT-PATHNAME-DEFAULTS*, so one
solution would be to set this variable manually every time, before loading
FOO. That's a real nuisance, which I'd like to avoid if possible. Another
possibility would be to add a line at the beginning of FOO to set
*DEFAULT-PATHNAME-DEFAULTS*, but that also loses because (a) every time I
made a new copy of the software I would have to edit FOO, and (b) when I
want to replace one version of the software with another, as when replacing
the contents of directory old/ with current/ and current/ with new/, I
would have to make sure NOT to copy the header file. The potential for
problems if the header file is accidentally copied is too great.
In some implementations (either the Symbolics or the TI machine I worked on
about 2 years ago), a call to LOAD embedded in a file appeared to get its
pathname defaults from the pathname of the parent file being loaded, but
this doesn't appear to be part of the Common Lisp standard. In other
implementations I seem to recall LOAD rebinding *STANDARD-INPUT*, so I
could snarf the actual pathname information from there. But in CMU Common
Lisp, LOAD does not rebind *STANDARD-INPUT*, and CLtL doesn't seem to
require this. So...
1. Anybody know a *portable* trick I can use to get embedded calls to LOAD
to use the parent file's pathname as a default?
2. How terrible would it be for LOAD to rebind *DEFAULT-PATHNAME-DEFAULTS* ?
3. Alternatively, what would people think of adding a :PARENT-PATH keyword
to LOAD. With a value of T this keyword would mean "if this is an embedded
load, get default pathname information from the pathname of the parent
file" ?
-- Dave
∂13-Dec-88 2107 Common-Lisp-mailer Common Lisp for SUNS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 13 Dec 88 21:07:27 PST
Received: from decwrl.dec.com by labrea.stanford.edu with TCP; Tue, 13 Dec 88 21:06:07 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for labrea!sail.stanford.edu!common-lisp; id AA07389; Tue, 13 Dec 88 21:06:33 PST
Received: by pyramid.pyramid.com (5.51/OSx4.4-880707)
id AA14035; Tue, 13 Dec 88 18:58:33 PST
Received: by neat.ai.toronto.edu with UUCP id 38064; Tue, 13 Dec 88 16:21:52 EST
Received: by nexus.yorku.ca with UUCP id 28713; Tue, 13 Dec 88 13:14:31 EST
Received: from istsai.yorku.ca by ists.yorku.ca (3.2/smail2.5/15-05-88)
id AA09454; Tue, 13 Dec 88 02:45:21 EST
Date: Tue, 13 Dec 88 02:46:37 EST
From: mike@ists.yorku.ca
Message-Id: <8812130746.AA03313@istsai.yorku.ca>
To: bill@red.ipsa.dnd.ca
Cc: common-lisp@sail.stanford.edu
In-Reply-To: IN%"bill@red.ipsa.dnd.ca"'s message of 29 NOV 88 11:47 EST
Subject: Common Lisp for SUNS
I have some experiences.
Give me a call at 416-736-5611 if you wnat to talk.
Mike.
∂14-Dec-88 0813 Common-Lisp-mailer RE: load defaults
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 14 Dec 88 08:13:15 PST
Received: from vax2.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
id AA02232; Wed, 14 Dec 88 11:14:26 est
Message-Id: <8812141614.AA02232@crash.cs.umass.edu>
Date: Wed, 14 Dec 88 11:11 EST
From: MURRAY@cs.umass.EDU
Subject: RE: load defaults
To: common-lisp@sail.stanford.EDU
X-Vms-To: IN%"common-lisp@sail.stanford.EDU"
> From: Dave.Touretzky@B.GP.CS.CMU.EDU
>I have a problem with the way Common Lisp says pathname defaults should be
> handled during load...
My initial reaction is that you should be using some sort of defsystem,
which gives you much more control over sets of files.
But maybe you're trying to run bare-bones.
>1. Anybody know a *portable* trick I can use to get embedded calls to LOAD
>to use the parent file's pathname as a default?
There is no portable way to find out what pathname is currently being
loaded. The portable way to get your desired behavior is simply to define your own
load function that will bind *DEFAULT-PATHNAME-DEFAULTS* to the file it
is loading before it calls the real load.
(defun default-load (input &rest args)
(let ((*default-pathname-defaults* (merge-pathnames input)))
(apply 'load *default-pathname-defaults* args)))
>2. How terrible would it be for LOAD to rebind *DEFAULT-PATHNAME-DEFAULTS* ?
Probably not too terrible, but it does create another instance of
a problem that some people have complained about. By having LOAD bind
a special variable, it make it impossible to have the contents of a
file side-effect that variable after the load. This is a current problem
with *package*.
>3. Alternatively, what would people think of adding a :PARENT-PATH keyword
>to LOAD. With a value of T this keyword would mean "if this is an embedded
>load, get default pathname information from the pathname of the parent
>file" ?
Surely you jest!
Kelly Murray
∂14-Dec-88 0959 Common-Lisp-mailer RE: load defaults
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Dec 88 09:59:23 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA28669; Wed, 14 Dec 88 09:59:57 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA27264; Wed, 14 Dec 88 09:56:35 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA14360; Wed, 14 Dec 88 09:57:31 PST
Date: Wed, 14 Dec 88 09:57:31 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8812141757.AA14360@clam.sun.com>
To: Dave.Touretzky@B.GP.CS.CMU.EDU, MURRAY@cs.umass.EDU,
common-lisp@sail.stanford.EDU
Subject: RE: load defaults
Some implementations of Common Lisp include a special variable
with a name like *source-pathname*, which is bound appropriately
by LOAD. This supports what is commonly known as "source code
recording" and if added to Common Lisp would meet needs such
as Touretzky's. We have found need for this at Sun and would
be happy to see such a thing in the language at some time.
-Cris
∂14-Dec-88 1619 Common-Lisp-mailer Re: load defaults
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Dec 88 16:19:18 PST
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 14 Dec 88 19:17:08 EST
To: common-lisp@sail.stanford.EDU
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: Re: load defaults
In-reply-to: Your message of Wed, 14 Dec 88 11:11:00 -0500.
<8812141614.AA02232@crash.cs.umass.edu>
Date: Wed, 14 Dec 88 19:16:51 EST
Message-ID: <3154.598148211@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU
> Date: Wed, 14 Dec 88 11:11 EST
> From: MURRAY@cs.umass.EDU
>
> There is no portable way to find out what pathname is currently being
> loaded. The portable way to get your desired behavior is simply to
> define your own load function that will bind *DEFAULT-PATHNAME-DEFAULTS*
> to the file it is loading before it calls the real load.
> (defun default-load (input &rest args)
> (let ((*default-pathname-defaults* (merge-pathnames input)))
> (apply 'load *default-pathname-defaults* args)))
This is a nice idea, but it doesn't solve my problem. The user would have
to type in the whole definition before he could use it to load the header
file I referred to. I want to avoid inconveniencing the user; he should be
able to just start up a fresh Lisp, LOAD a single header file, and have
everything else happen automatically.
I like KMP's proposals. I like the second one best: have separate
variables for files being loaded and files being compiled, and use them to
maintain a stack so we can see the nesting of loads within files.
-- Dave
∂15-Dec-88 1720 Common-Lisp-mailer WG16 document N31, "Working documents on CALLING MECHANISMS..."
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 15 Dec 88 17:20:23 PST
Date: Thu, 15 Dec 88 09:55:14 PST
From: Thom Linden <baggins@ibm.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <881215.095514.baggins@IBM.com>
Subject: WG16 document N31, "Working documents on CALLING MECHANISMS..."
I have a copy of the document Jeff mentioned and will bring it to
the Jan. meeting.
Thom
∂15-Dec-88 1853 CL-Compiler-mailer dumping weird objects to compiled files
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 15 Dec 88 18:53:10 PST
Posted-Date: Thu, 15 Dec 88 18:52:28 PST
Message-Id: <8812160252.AA06530@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
id AA06530; Thu, 15 Dec 88 18:52:31 PST
To: common-lisp@sail.stanford.edu, cl-compiler@sail.stanford.edu
Cc: lwolf%franz.uucp@berkeley.edu
Subject: dumping weird objects to compiled files
Date: Thu, 15 Dec 88 18:52:28 PST
From: Don Cohen <donc@vaxa.isi.edu>
The commonlisp spec is quite vague on what exactly the compiler
should do and provides no control over how or whether strange
objects can be dumped at all. However, in the case of structures
it does provide for a print function. Suppose I have a function
F that uses a macro M which expands into some structure of type S.
1. If I give S a print function, can I expect that when I compile F
to a file, that print function will be used to write something to
the compiled file that will be read to return the "corresponding"
object when the file is loaded? (I'm interested in justifications
for either answer.) The other possibility is that the compiler
would ignore the print function and dump something that would,
when loaded, create a structure of type S and fill its slots with
objects that were recursively dumped. If I could count on my print
function being used, I could arrange for it to print something that
would "do the right thing".
2. If you don't think that my expectation is justified, do you
think the commonlisp spec ought to say that it is (thereby making
it so).
This "trick" would allow us to write a macro that allows macros
to generate the analog of #, which I think is a feature sorely
missed in commonlisp. This in turn would go a long way toward
solving what I regard as a problem with the spec - that EQUAL
values may be identified. This is a solution just because it
returns control over what things are EQ to the user, who knows
which things he wants to be EQ, which things he does NOT want EQ
and which don't matter.
∂16-Dec-88 0123 Common-Lisp-mailer file loading query
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Dec 88 01:22:59 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00971g; Fri, 16 Dec 88 01:20:08 PST
Received: by bhopal id AA20998g; Fri, 16 Dec 88 01:22:08 PST
Date: Fri, 16 Dec 88 01:22:08 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812160922.AA20998@bhopal>
To: Dave.Touretzky@cs.cmu.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Tue, 13 Dec 88 20:04:24 EST <2131.598064664@DST.BOLTZ.CS.CMU.EDU>
Subject: file loading query
re: 1. Anybody know a *portable* trick I can use to get embedded calls to LOAD
to use the parent file's pathname as a default?
I doubt that there's a portable trick. Lucid Common Lisp supports an
extension as follows:
(defvar *load-pathname* nil
"During a load, this is bound to the pathname of the file being loaded.")
and ocasionally it is used to find out what directory the currently
loading file is on, so that a related file can be loaded from the same
directory.
-- JonL --
∂16-Dec-88 0733 CL-Compiler-mailer Re: dumping weird objects to compiled files
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Dec 88 07:32:56 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA06704; Fri, 16 Dec 88 08:31:57 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA05675; Fri, 16 Dec 88 08:31:53 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8812161531.AA05675@defun.utah.edu>
Date: Fri, 16 Dec 88 08:31:51 MST
Subject: Re: dumping weird objects to compiled files
To: Don Cohen <donc@vaxa.isi.edu>
Cc: common-lisp@sail.stanford.edu, cl-compiler@sail.stanford.edu,
lwolf%franz.uucp@berkeley.edu
In-Reply-To: Don Cohen <donc@vaxa.isi.edu>, Thu, 15 Dec 88 18:52:28 PST
The cl-compiler subcommittee is in the midst of preparing a set of
elaborate proposals to submit to X3J13 to detail exactly what kinds of
constant objects may be compiled. We do think it is important for the
ANSI standard to say more than CLtL does about this.
At the moment we appear to be heading towards the conclusion that the
dump/load transformation on structures created with DEFSTRUCT ought to
always create a structure isomorphic to the original, regardless of
whether or not that structure type has a user-supplied :PRINT-FUNCTION.
However, we have also talked about something similar to the dump/load
protocol you describe in the context of arbitrary CLOS objects.
-Sandra
-------
∂16-Dec-88 0843 Common-Lisp-mailer Re: dumping weird objects to compiled files
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 16 Dec 88 08:43:29 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA27569; Fri, 16 Dec 88 08:45:46 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA02972; Fri, 16 Dec 88 08:42:27 PST
Received: by clam.sun.com (3.2/SMI-3.2)
id AA17011; Fri, 16 Dec 88 08:43:24 PST
Date: Fri, 16 Dec 88 08:43:24 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8812161643.AA17011@clam.sun.com>
To: cl-compiler@sail.stanford.edu, donc@vaxa.isi.edu
Subject: Re: dumping weird objects to compiled files
Cc: common-lisp@sail.stanford.edu, lwolf%franz.uucp@berkeley.edu
Hi Don!
I'm working on a proposal on this exact issue, i.e. what Common
Lisp is supposed to do about (quoted) constants in compiled files.
There are big holes in the definition of Common Lisp today
concerning compilation, and this is one of them.
To answer one of your questions, no you definitely cannot
expect your constants to be PRINTed into compiled files. Most
implementations use some binary representation of data.
There is interest in supporting user-defined types (structures
and classes) with user-definable dumpers, but it's just too much
work for me to personally try to address that. Hopefully some
good facility will get defined.
There is also interest in something comparable to #, that is not
a readmacro, so you can sensibly generate them in programs and
at least one proposal for that.
You can mail to me for more information.
-Cris
∂16-Dec-88 1821 Common-Lisp-mailer file loading query
Received: from trwrb.dsd.trw.com (TRWRB.TRW.COM) by SAIL.Stanford.EDU with TCP; 16 Dec 88 18:21:13 PST
Received: by trwrb.dsd.trw.com (5.51/1.36)
id AA14762; Fri, 16 Dec 88 18:18:22 PST
From: smpvax1!daemon@trwrb.dsd.trw.com
Received: by smpvax1.inference.com (3.2/SMI-3.2 SBB's version)
id AA07290; Fri, 16 Dec 88 17:30:56 PST
Date: Fri, 16 Dec 88 17:30:56 PST
Message-Id: <8812170130.AA07290@smpvax1.inference.com>
To: Dave.Touretzky\@cs.cmu.edu@trwrb.dsd.trw.com,
ucbvax!lucid.com!jonl@trwrb.dsd.trw.com
Cc: common-lisp\@sail.stanford.edu@trwrb.dsd.trw.com
In-Reply-To: Jon L White's message of Fri, 16 Dec 88 01:22:08 PST <8812160922.AA20998@bhopal>
Subject: file loading query
re: 1. Anybody know a *portable* trick I can use to get embedded calls to LOAD
to use the parent file's pathname as a default?
You needn't be a privileged implementor to use Lucid's idea.
This should be portable:
(defvar *my-load-pathname* nil)
(defun my-load (partial-path)
(let ((*my-load-pathname* (merge-pathnames partial-path *my-load-pathname*)))
(load *my-load-pathname*)))
and replace all calls to load in files with calls to my-load, e.g.,
(my-load "What-a-moaning")
A more general thing involving twiddling the prefix of a directory tree
from which embedded loads will occur in various subdirectories might be
(defun load-from-subtree (partial-path path-function)
(let ((*my-load-pathname* (funcall path-function partial-path *my-load-pathname*)))
(load *my-load-pathname*)))
and replace embedded load calls with load-from-subtree. Typically the
path-function will concatenate the directories of *my-load-pathname* and
partial-path, or something. At least on Lucid 3.0, merge-pathnames serves
as such a function, as in (merge-pathnames "arith/bignum" "~/broken/mork.bin").
Jeff Greif
Inference Corp.
∂22-Dec-88 1219 Common-Lisp-mailer commonlisp types
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Dec 88 12:18:57 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 511560; Thu 22-Dec-88 15:17:50 EST
Date: Thu, 22 Dec 88 15:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: commonlisp types
To: gls@Think.COM
cc: jwz@spice.cs.cmu.edu, common-lisp@sail.stanford.edu
In-Reply-To: <8812021633.AA05964@verdi.think.com>
Message-ID: <881222151736.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 2 Dec 88 11:33:22 EST
From: Guy Steele <gls@Think.COM>
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
...
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
I can see that the compiler could have special knowledge about
such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
"to avoid scoping problems."
Consider
(defun bazola (linguini pop-tarts)
(declare (type (satisfies (lambda (x) (< x linguini))) pop-tarts))
...)
I'm trying to say that pop-tarts is always smaller in value than linguini.
The lambda expression appears lexically within the binding of linguini,
so one might expect that the free reference to linguini is legitimate.
But it can't work.
Similarly this cannot work:
(defun bazola (linguini pop-tarts)
(assert (typep pop-tarts '(satisfies (lambda (x) (< x linguini)))))
...)
[Of course, this can be rendered instead as
(defun bazola (linguini pop-tarts)
(assert (< pop-tarts linguini))
...)
but that is beside the point.]
One might conceivably argue that SATISFIES should allow an actual
function and not just a name; then one might try
(defun bazola (linguini pop-tarts)
(assert (typep pop-tarts `(satisfies ,(lambda (x) (< x linguini)))))
...)
but this approach doesn't help the declaration case. It's a basic problem
of compile-time versus run-time execution.
--Guy
Fyi, it turns out this rationale doesn't hold as much water as you'd think.
Consider:
(defun bar (x) (symbolp x))
(defun foo (x)
(flet ((bar (y) (integerp y)))
(typep x '(satisfies bar))))
(foo 'x)
The correct answer is T, but I bet a lot of implementations return NIL
in compiled code.
Anyway, my main point is that the reason for prohibiting lambda expressions
isn't that they're not meaningful, only that they're hard to reason about.
But since an analogous argument can be made for symbols, the rationale breaks
down.
Since (SATISFIES BAR) means that (FUNCALL (SYMBOL-FUNCTION 'BAR) ...) is
true, not that (FUNCALL #'BAR ...) is true, then it follows that
(SATISFIES (LAMBDA (X) (AND (BAR X) (BAZ X)))) means
(FUNCALL (EVAL '#'(LAMBDA (X) (AND (BAR X) (BAZ X)))) ...) is true, not
that
(FUNCALL #'(LAMBDA (X) (AND (BAR X) (BAZ X))) ...) is true.
The real truth is that we thought the scoping problems were limited to
LAMBDA expressions because we weren't used to reasoning about FLET, which
was a new construct at the time we designed CL. If we had it to do over,
I'd certainly be lobbying strongly for permitting lambda expressions.
The Common-Lisp mailing list doesn't have the authority to change the
language, so I'll save any proposals to change things for other forums.
But I did want to publicly debunk the myth behind this design decision.
Btw, if LAMBDA expressions -were- permitted, the BAZOLA example you suggest
could, in addition to the more obvious way you cite, be written as:
(defun bazola (linguini pop-tarts)
(declare (special linguini))
(assert (typep pop-tarts '(satisfies (lambda (x)
(declare (special linguini))
(< x linguini)))))
...)
This works even if you open code it in the obvious way, though it has
the disadvantage that figuring out that the SPECIAL declaration was needed
only for the sake of the transition into the SATISFIES and not for some
function called within the opened LAMBDA may be tricky. So the open-coded
form may do a needless special bind in complex cases involving calls to
user-defined predicates.
∂27-Dec-88 0819 Common-Lisp-mailer Experiences porting applications from Symbolics
Received: from gateway.mitre.org by SAIL.Stanford.EDU with TCP; 27 Dec 88 08:19:42 PST
Received: by gateway.mitre.org (5.54/SMI-2.2)
id AA10060; Tue, 27 Dec 88 11:15:04 EST
Return-Path: <howell%community-chest.mitre.org@gateway.mitre.org>
Received: by chance.mitre.org (3.2/SMI-2.2)
id AA21082; Tue, 27 Dec 88 11:12:23 EST
From: howell%community-chest.mitre.org@gateway.mitre.org
Message-Id: <8812271612.AA21082@chance.mitre.org>
To: ailist@ai.ai.mit.edu, common-lisp@sail.stanford.edu,
slug@warbucks.ai.sri.com
Cc: howell@mitre.ARPA
Subject: Experiences porting applications from Symbolics
Date: Tue, 27 Dec 88 11:12:21 -0500
I'm trying to make a quick and dirty estimate of the level of effort
required to port a local application from the Symbolics to other hosts
(probably a microvax II or an HP 9000). Any experiences with such a port
(to any other hosts, not just the HP or microVax) would be very helpful.
For example, did you encounter problems with variant semantics in different
Common Lisp compilers? What kind of support did the new host provide for
mouse-sensitive bit-mapped graphics, and for access to them? Did you find
that your application depended on Symbolics-provided function libraries or
"OS services", or was your application relatively host-independent?
Any big "gotchas" that you didn't expect?
Thanks in advance for any replies.
Chuck Howell, MITRE
howell@mitre.mitre.org
(703) 883-6080
∂02-Jan-89 1238 Common-Lisp-mailer commonlisp types
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 12:37:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514019; Mon 2-Jan-89 15:35:56 EST
Date: Mon, 2 Jan 89 15:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: commonlisp types
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: gls@Think.COM, jwz@spice.cs.cmu.edu, common-lisp@sail.stanford.edu
In-Reply-To: <881222151736.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890102203526.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 22 Dec 88 15:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Fri, 2 Dec 88 11:33:22 EST
From: Guy Steele <gls@Think.COM>
Date: Fri, 2 Dec 1988 00:40-EST
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
...
Can someone explain the rationale behind forcing SATISFIES to
accept only function-names and not lambda expressions?
....
Fyi, it turns out this rationale doesn't hold as much water as you'd think.
Consider:
(defun bar (x) (symbolp x))
(defun foo (x)
(flet ((bar (y) (integerp y)))
(typep x '(satisfies bar))))
(foo 'x)
The correct answer is T, but I bet a lot of implementations return NIL
in compiled code.
....
The real truth is that we thought the scoping problems were limited to
LAMBDA expressions because we weren't used to reasoning about FLET, which
was a new construct at the time we designed CL. If we had it to do over,
I'd certainly be lobbying strongly for permitting lambda expressions.
You're right. I think what really happened is not that we weren't used
to FLET, but that FLET and LABELS were added to the language after
type-specifiers had been designed, and the full ramifications of FLET on
the rest of the language were not explored at the time it was added.
∂03-Jan-89 0340 Common-Lisp-mailer commonlisp types
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 3 Jan 89 03:39:54 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 305296; 3 Jan 89 06:37:40 EST
Date: Tue, 3 Jan 89 05:35 EST
From: Robert W. Kerns <RWK@F.ILA.Dialnet.Symbolics.COM>
Subject: commonlisp types
To: jonl%lucid.com@RIVERSIDE.SCRC.SYMBOLICS.COM, common-lisp%sail.stanford.edu@RIVERSIDE.SCRC.SYMBOLICS.COM
In-Reply-To: <8812070546.AA11501@bhopal>
Supersedes: <19890103090720.6.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-ID: <19890103103558.4.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Tue, 6 Dec 88 21:46:27 PST
From: Jon L White <jonl@lucid.com>
re: There seems to be nothing in CLtL that answers the question:
"is x a legal type specifier?"
At the meeting that founded the X3J13 committee (on 6-Dec-85), Guy Steele
circulated a list of "non-controversial issues" and "Clarifications"
which included the following addition [typos faithfully reproduced]:
"(*) 51 Add a newefunction TYPE-SPECIFIER-P that is true of valid type
specifiers and fals of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time."
Sad to say, this and many other "non-controversial" items included in
Guy's list of "Clarifications", has never been brought up in the X3J13
"Cleanup" subcommittee. However, Lucid's 3.0 release includes such
a function.
How do you define "valid type specifier"?
(deftype foo (x)
(car x))
(typep 'yow '(foo a))
==> Error taking CAR of the symbol A.
(type-specifier-p '(foo a))
==> ?
I would guess probably T, but then, how do you word the definition?
If not, how do you define it?
∂03-Jan-89 1714 Common-Lisp-mailer PROG1 as a function
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89 17:14:00 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 3 Jan 89 19:44:12 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 3 Jan 89 20:10:55 EST
Date: Tue, 3 Jan 89 20:10 EST
From: Barry Margolin <barmar@Think.COM>
Subject: PROG1 as a function
To: common-lisp@sail.stanford.edu
Message-Id: <19890104011056.6.BARMAR@OCCAM.THINK.COM>
One of our users noticed today that Symbolics defines PROG1 as a
function, rather than as a macro as CLtL specifies. The definition is
essentially
(defun prog1 (first-form &rest rest-forms)
(declare (ignore rest-forms))
first-form)
This works because CL requires left-to-right evaluation of function
arguments; it just does a bit more consing than a macro implementation
would need to do. The compiler open-codes PROG1 invocations, so this is
only used in the interpreter.
Does this seem valid? The only implementation leeway CLtL mentions is
that macros may be implemented as special forms, so long as an
equivalent macro definition is also made available; it doesn't
specifically mention implementing macros as functions (probably because
the developers thought that none of them COULD be implemented as
functions).
I don't see how this could cause any code to fail.
barmar
∂04-Jan-89 0102 Common-Lisp-mailer commonlisp types
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 01:01:59 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04028g; Wed, 4 Jan 89 00:56:44 PST
Received: by bhopal id AA01403g; Wed, 4 Jan 89 00:58:57 PST
Date: Wed, 4 Jan 89 00:58:57 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901040858.AA01403@bhopal>
To: RWK@F.ILA.Dialnet.Symbolics.COM
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Robert W. Kerns's message of Tue, 3 Jan 89 05:35 EST <19890103103558.4.RWK@F.ILA.Dialnet.Symbolics.COM>
Subject: commonlisp types
re: How do you define "valid type specifier"?
Very syntactically. I think its perfectly acceptable to have a set
of combination rules for making "words" in the type-specifier syntax,
even though some such "words" would be gibberish.
The important thing is that base-level types -- those defined in
CLtL -- along with DEFSTRUCT extensions be recognizable. They don't
have the problems that SATISFIES generates, or that a broken user
definition generates (such as your DEFTYPE FOO example).
By the bye, on another note, I haven't seen any implementation that
has the bug Kent wondered about earlier:
(defun bar (x) (symbolp x))
(defun foo (x)
(flet ((bar (y) (integerp y)))
(typep x '(satisfies bar))))
(foo 'x)
The correct answer is T, but I bet a lot of implementations return NIL
in compiled code.
Anyone know of an implementation for which this fails?
-- JonL --
∂04-Jan-89 0537 Common-Lisp-mailer re: commonlisp types
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 4 Jan 89 05:37:09 PST
Received: from vax5.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
id AA05758; Wed, 4 Jan 89 08:38:09 est
Message-Id: <8901041338.AA05758@crash.cs.umass.edu>
Date: Wed, 4 Jan 89 08:37 EST
From: David Forster <FORSTER@cs.umass.EDU>
Subject: re: commonlisp types
To: common-lisp@sail.stanford.EDU
X-Vms-To: IN%"common-lisp@sail.stanford.edu"
The TI Explorer (4.2) is one of your problem cases -- it applies the flet'd
function in the `satisfies' clause, instead of the defun'd one.
∂04-Jan-89 0921 Common-Lisp-mailer PROG1 as a function; meta-rules of CLtL
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 09:21:03 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA04233g; Wed, 4 Jan 89 09:17:15 PST
Received: by blacksox id AA00451g; Wed, 4 Jan 89 09:19:35 pst
Date: Wed, 4 Jan 89 09:19:35 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901041719.AA00451@blacksox>
To: barmar@Think.COM
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 3 Jan 89 20:10 EST <19890104011056.6.BARMAR@OCCAM.THINK.COM>
Subject: PROG1 as a function; meta-rules of CLtL
Date: Tue, 3 Jan 89 20:10 EST
From: Barry Margolin <barmar@Think.COM>
One of our users noticed today that Symbolics defines PROG1 as a
function, rather than as a macro as CLtL specifies. The definition is
essentially
(defun prog1 (first-form &rest rest-forms)
(declare (ignore rest-forms))
first-form)
This works because CL requires left-to-right evaluation of function
arguments; it just does a bit more consing than a macro implementation
would need to do.
Actually, it doesn't do any more consing than the macro definition,
because &REST arguments are stack-allocated on Symbolics machines (in
generally-agreed-on violation of CLtL). Even in Lucid's implementation
this definition would not cons, because the ignored rest argument is
never created in the first place.
The compiler open-codes PROG1 invocations, so this is
only used in the interpreter.
Does this seem valid? The only implementation leeway CLtL mentions is
that macros may be implemented as special forms, so long as an
equivalent macro definition is also made available; it doesn't
specifically mention implementing macros as functions (probably because
the developers thought that none of them COULD be implemented as
functions).
I don't see how this could cause any code to fail.
barmar
Someone writing a cross-compiler or other codewalking tool that did
macroexpansion might be surprised that PROG1 was not expanded. This
might not be a problem if the result were going to run in the same
environment, but it could cause trouble if it were going to be used in
an environment where PROG1 is a macro.
CLtL is silent on this topic (like many others). It is not
explicitly prohibited, nor is it explicitly permitted. This raises a
meta-question: If something is not mentioned, does that mean it is
permitted, or does that mean it is prohibited? I think it must be the
former, since CLtL defines a "core" language, which may be extended by
the implementor. The cleanup committee has tried to fill many of
these holes, but it is impossible to deal with all of them. It is
safe to say that ambiguities will be discovered as long as there are
prople using Common Lisp. Here are some choice ones, in increasing
order of bizarreness:
Is it OK to define Common Lisp functions with extra optional or
keyword parameters, with system dependent meanings? E.g. Lucid's
COMPILE-FILE has several keyword arguments not mentioned in CLtL.
Is it OK to return extra values from Common Lisp functions?
Is it OK to define the behavior of functions on datatypes not
explicitly permitted in CLtL? For example, suppose I defined + on
vectors to do componentwise addition on the elements? Arguments to +
"must" be numbers, meaning that it "is an error" to supply anything
other than numbers, meaning that anything can happen when you supply
arguments other than numbers.
Suppose an implementation printed
>>Attention: Taking CAR of (1 2 3)!
every time CAR was called. I don't suppose many people would use
it, but would it be a legal Common Lisp implementation?
∂04-Jan-89 1054 Common-Lisp-mailer PROG1 as a function
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89 10:54:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515182; Wed 4-Jan-89 13:50:23 EST
Date: Wed, 4 Jan 89 13:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PROG1 as a function
To: Barry Margolin <barmar@Think.COM>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <19890104011056.6.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890104184948.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 3 Jan 89 20:10 EST
From: Barry Margolin <barmar@Think.COM>
One of our users noticed today that Symbolics defines PROG1 as a
function, rather than as a macro as CLtL specifies. The definition is
essentially
(defun prog1 (first-form &rest rest-forms)
(declare (ignore rest-forms))
first-form)
This works because CL requires left-to-right evaluation of function
arguments
CLtL is vague about the order of evaluation of function arguments. In
chapters 5 and 7 it neither says that the order is left-to-right nor
that the order is undefined, and I suspect that the person who made
PROG1 a macro thought the order was undefined; I can't see any other
reason that it would need to be a macro. The place in CLtL that says
that all function arguments are evaluated left-to-right is page 194,
buried in the middle of a discussion on numeric contagion.
∂04-Jan-89 1111 Common-Lisp-mailer PROG1 as a function
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89 11:11:19 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 515201; 4 Jan 89 14:09:38 EST
Date: Wed, 4 Jan 89 14:17 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PROG1 as a function
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, barmar@Think.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <19890104184948.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890104191710.7.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Date: Wed, 4 Jan 89 13:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 3 Jan 89 20:10 EST
From: Barry Margolin <barmar@Think.COM>
One of our users noticed today that Symbolics defines PROG1 as a
function, rather than as a macro as CLtL specifies. The definition is
essentially
(defun prog1 (first-form &rest rest-forms)
(declare (ignore rest-forms))
first-form)
This works because CL requires left-to-right evaluation of function
arguments
CLtL is vague about the order of evaluation of function arguments. In
chapters 5 and 7 it neither says that the order is left-to-right nor
that the order is undefined, and I suspect that the person who made
PROG1 a macro thought the order was undefined; I can't see any other
reason that it would need to be a macro. The place in CLtL that says
that all function arguments are evaluated left-to-right is page 194,
buried in the middle of a discussion on numeric contagion.
Actually, CLtL pg 61 says that the arguments and parameters are
processed in order, from left to right. I don't know if "processed"
implies "evaluated", but I always assumed (perhaps incorrectly) it did.
∂04-Jan-89 1131 Common-Lisp-mailer PROG1 as a function
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89 11:31:24 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515226; Wed 4-Jan-89 14:29:52 EST
Date: Wed, 4 Jan 89 14:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PROG1 as a function
To: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
cc: barmar@Think.COM, common-lisp@sail.stanford.edu
In-Reply-To: <19890104191710.7.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Message-ID: <19890104192915.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 4 Jan 89 14:17 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Date: Wed, 4 Jan 89 13:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
CLtL is vague about the order of evaluation of function arguments.
Actually, CLtL pg 61 says that the arguments and parameters are
processed in order, from left to right. I don't know if "processed"
implies "evaluated", but I always assumed (perhaps incorrectly) it did.
"Arguments" are the output from evaluation, not the input to evaluation.
Think about the case where the function was called by APPLY.
∂04-Jan-89 1252 Common-Lisp-mailer PROG1 as a function; meta-rules of CLtL
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89 12:51:58 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 4 Jan 89 15:06:58 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 4 Jan 89 15:48:06 EST
Date: Wed, 4 Jan 89 15:47 EST
From: Barry Margolin <barmar@Think.COM>
Subject: PROG1 as a function; meta-rules of CLtL
To: Eric Benson <eb@lucid.com>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8901041719.AA00451@blacksox>
Message-Id: <19890104204747.1.BARMAR@OCCAM.THINK.COM>
Date: Wed, 4 Jan 89 09:19:35 pst
From: Eric Benson <eb@lucid.com>
Date: Tue, 3 Jan 89 20:10 EST
From: Barry Margolin <barmar@Think.COM>
One of our users noticed today that Symbolics defines PROG1 as a
function, rather than as a macro as CLtL specifies. The definition is
essentially
(defun prog1 (first-form &rest rest-forms)
(declare (ignore rest-forms))
first-form)
This works because CL requires left-to-right evaluation of function
arguments; it just does a bit more consing than a macro implementation
would need to do.
Actually, it doesn't do any more consing than the macro definition,
because &REST arguments are stack-allocated on Symbolics machines (in
generally-agreed-on violation of CLtL). Even in Lucid's implementation
this definition would not cons, because the ignored rest argument is
never created in the first place.
True. I didn't realize that EVAL consed the arguments on the stack (I
thought only compiled code did it).
Is it OK to define Common Lisp functions with extra optional or
keyword parameters, with system dependent meanings? E.g. Lucid's
COMPILE-FILE has several keyword arguments not mentioned in CLtL.
Is it OK to return extra values from Common Lisp functions?
Is it OK to define the behavior of functions on datatypes not
explicitly permitted in CLtL? For example, suppose I defined + on
vectors to do componentwise addition on the elements? Arguments to +
"must" be numbers, meaning that it "is an error" to supply anything
other than numbers, meaning that anything can happen when you supply
arguments other than numbers.
Those of us in X3J13 have been thinking about this general problem for
several years, but there still isn't a clear concensus. I believe that
it was the original intent of the CL designers that implementations be
permitted to do many of these things. Anything that "is an error" is a
potential place for extension. Symbolics has done all of the above.
Adding optional parameters or returning extra values is usually safe.
Programs can get in trouble, though, if they use multiple-value-list or
multiple-value-call with functions that have been extended in such ways.
For instance, (multiple-value-call #'cons (floor x y)) looks portable,
but it will try to pass the wrong number of arguments to CONS if FLOOR
returns an extra value.
Suppose an implementation printed
>>Attention: Taking CAR of (1 2 3)!
every time CAR was called. I don't suppose many people would use
it, but would it be a legal Common Lisp implementation?
This is something I remember Kent Pitman bringing up a long time ago,
under the general topic of automatic output. The above is obviously an
extreme case, but there are realistic analogues, such as GC
notifications, autoload heralds, and progress messages from COMPILE-FILE
or LOAD. Since we weren't sure how to tackle these, we've generally
dismissed them as "environment" features, which CL generally doesn't
address.
barmar
∂04-Jan-89 1328 Common-Lisp-mailer PROG1 as a function
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89 13:28:19 PST
Received: from fafnir.think.com by Think.COM; Wed, 4 Jan 89 15:44:14 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 4 Jan 89 16:25:37 EST
Received: by verdi.think.com; Wed, 4 Jan 89 16:23:48 EST
Date: Wed, 4 Jan 89 16:23:48 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901042123.AA10344@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: barmar@Think.COM, common-lisp@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 4 Jan 89 13:49 EST <19890104184948.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: PROG1 as a function
Date: Wed, 4 Jan 89 13:49 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Tue, 3 Jan 89 20:10 EST
From: Barry Margolin <barmar@Think.COM>
One of our users noticed today that Symbolics defines PROG1 as a
function, rather than as a macro as CLtL specifies. The definition is
essentially
(defun prog1 (first-form &rest rest-forms)
(declare (ignore rest-forms))
first-form)
This works because CL requires left-to-right evaluation of function
arguments
CLtL is vague about the order of evaluation of function arguments. In
chapters 5 and 7 it neither says that the order is left-to-right nor
that the order is undefined, and I suspect that the person who made
PROG1 a macro thought the order was undefined; I can't see any other
reason that it would need to be a macro. The place in CLtL that says
that all function arguments are evaluated left-to-right is page 194,
buried in the middle of a discussion on numeric contagion.
Sigh. Unfortunately, I must beg to differ. I read the passage on page 194
as requiring only that the fully evaluated arguments be processed
left-to-right for contagion purposes. This is not the same as requiring
that argument forms in a call be evaluated left-to-right.
-- Guy
∂04-Jan-89 1333 Common-Lisp-mailer PROG1 as a function
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89 13:29:47 PST
Received: from fafnir.think.com by Think.COM; Wed, 4 Jan 89 15:46:00 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 4 Jan 89 16:27:29 EST
Received: by verdi.think.com; Wed, 4 Jan 89 16:25:43 EST
Date: Wed, 4 Jan 89 16:25:43 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901042125.AA10347@verdi.think.com>
To: Greenwald@stony-brook.scrc.symbolics.com
Cc: Moon@stony-brook.scrc.symbolics.com, barmar@Think.COM,
common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Wed, 4 Jan 89 14:17 EST <19890104191710.7.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Subject: PROG1 as a function
Date: Wed, 4 Jan 89 14:17 EST
From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>
Date: Wed, 4 Jan 89 13:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 3 Jan 89 20:10 EST
From: Barry Margolin <barmar@Think.COM>
One of our users noticed today that Symbolics defines PROG1 as a
function, rather than as a macro as CLtL specifies. The definition is
essentially
(defun prog1 (first-form &rest rest-forms)
(declare (ignore rest-forms))
first-form)
This works because CL requires left-to-right evaluation of function
arguments
CLtL is vague about the order of evaluation of function arguments. In
chapters 5 and 7 it neither says that the order is left-to-right nor
that the order is undefined, and I suspect that the person who made
PROG1 a macro thought the order was undefined; I can't see any other
reason that it would need to be a macro. The place in CLtL that says
that all function arguments are evaluated left-to-right is page 194,
buried in the middle of a discussion on numeric contagion.
Actually, CLtL pg 61 says that the arguments and parameters are
processed in order, from left to right. I don't know if "processed"
implies "evaluated", but I always assumed (perhaps incorrectly) it did.
I interpret this as referring to how the (fully evaluated) arguments
are processed during lambda-binding, not to the order in which argument
forms in a function call are evaluated. After all, the arguments referred
to on page 61 might have come from a list given to APPLY, rather then
from EVAL on a function call.
--Guy
∂04-Jan-89 1337 Common-Lisp-mailer PROG1 as a function
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 13:37:19 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA04590g; Wed, 4 Jan 89 13:32:41 PST
Received: by blacksox id AA00501g; Wed, 4 Jan 89 13:34:57 pst
Date: Wed, 4 Jan 89 13:34:57 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901042134.AA00501@blacksox>
To: gls@Think.COM
Cc: Moon@stony-brook.scrc.symbolics.com, barmar@Think.COM,
common-lisp@sail.stanford.edu
In-Reply-To: Guy Steele's message of Wed, 4 Jan 89 16:23:48 EST <8901042123.AA10344@verdi.think.com>
Subject: PROG1 as a function
Date: Wed, 4 Jan 89 16:23:48 EST
From: Guy Steele <gls@Think.COM>
Sigh. Unfortunately, I must beg to differ. I read the passage on page 194
as requiring only that the fully evaluated arguments be processed
left-to-right for contagion purposes. This is not the same as requiring
that argument forms in a call be evaluated left-to-right.
-- Guy
Maybe you're looking at the wrong passage. This looks pretty
unambiguous to me. It's also the only place in CLtL that says
argument evaluation is always left-to-right:
"For functions that are mathematically associative (and possibly
commutative), a Common Lisp implementation may process the arguments
in any manner consistent with associative (and possibly commutative)
rearrangement. This does not affect the order in which the argument
forms are evaluated, of course; that order is always left-to-right, as
in all Common Lisp function calls. What is left loose is the order in
which the argument values are processed."
∂04-Jan-89 1354 Common-Lisp-mailer Re: PROG1 as a function; meta-rules of CLtL
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 13:54:26 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA07451; Wed, 4 Jan 89 16:53:07 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA14516; Wed, 4 Jan 89 16:53:06 EST
Message-Id: <8901042153.AA14516@mist.>
To: Barry Margolin <barmar@Think.COM>
Cc: Eric Benson <eb@lucid.com>, common-lisp@sail.stanford.edu
Subject: Re: PROG1 as a function; meta-rules of CLtL
In-Reply-To: Your message of Wed, 04 Jan 89 15:47:00 -0500.
<19890104204747.1.BARMAR@OCCAM.THINK.COM>
Date: Wed, 04 Jan 89 16:53:00 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Wed, 4 Jan 89 15:47 EST
From: Barry Margolin <barmar@Think.COM>
Date: Wed, 4 Jan 89 09:19:35 pst
From: Eric Benson <eb@lucid.com>
Is it OK to define Common Lisp functions with extra optional or
keyword parameters, with system dependent meanings? E.g. Lucid's
COMPILE-FILE has several keyword arguments not mentioned in CLtL.
Is it OK to return extra values from Common Lisp functions?
Is it OK to define the behavior of functions on datatypes not
explicitly permitted in CLtL? For example, suppose I defined + on
vectors to do componentwise addition on the elements? Arguments to +
"must" be numbers, meaning that it "is an error" to supply anything
other than numbers, meaning that anything can happen when you supply
arguments other than numbers.
Those of us in X3J13 have been thinking about this general problem for
several years, but there still isn't a clear concensus. I believe that
it was the original intent of the CL designers that implementations be
permitted to do many of these things. Anything that "is an error" is a
potential place for extension. Symbolics has done all of the above.
Adding optional parameters or returning extra values is usually safe.
I have to disagree. Adding new keyword parameters is fairly safe,
since a new version of the Common Lisp standard would have to use that
exact keyword name in an incompatible way to cause a problem. However
adding a new optional parameter guarantees that any new standard which
adds a new optional or required parameter to the form will cause
trouble (unless, of course, the change in the standard was to adopt
the implementation extension in question). Since the Common Lisp
standard is (and will be, I hope) created by consensus as much as
possible, the most likely effect of such an implementation extension
is to restrict the options of any new standard. I would personally
encourage implementations to make any additions to Common Lisp forms
via new keyword arguments rather than optional arguments; I hope that
the final X3J13 standard will specify this.
Returning extra values is a harder problem. It causes the same
problems as new optional arguments, but there is more likely to be no
reasonable alternative.
∂04-Jan-89 1414 Common-Lisp-mailer PROG1 as a function
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89 14:13:58 PST
Received: from fafnir.think.com by Think.COM; Wed, 4 Jan 89 16:16:10 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 4 Jan 89 16:57:36 EST
Received: by verdi.think.com; Wed, 4 Jan 89 16:55:50 EST
Date: Wed, 4 Jan 89 16:55:50 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901042155.AA10486@verdi.think.com>
To: eb@lucid.com
Cc: gls@Think.COM, Moon@stony-brook.scrc.symbolics.com, barmar@Think.COM,
common-lisp@sail.stanford.edu
In-Reply-To: Eric Benson's message of Wed, 4 Jan 89 13:34:57 pst <8901042134.AA00501@blacksox>
Subject: PROG1 as a function
Date: Wed, 4 Jan 89 13:34:57 pst
From: Eric Benson <eb@lucid.com>
Date: Wed, 4 Jan 89 16:23:48 EST
From: Guy Steele <gls@Think.COM>
Sigh. Unfortunately, I must beg to differ. I read the passage on page 194
as requiring only that the fully evaluated arguments be processed
left-to-right for contagion purposes. This is not the same as requiring
that argument forms in a call be evaluated left-to-right.
-- Guy
Maybe you're looking at the wrong passage. This looks pretty
unambiguous to me. It's also the only place in CLtL that says
argument evaluation is always left-to-right:
"For functions that are mathematically associative (and possibly
commutative), a Common Lisp implementation may process the arguments
in any manner consistent with associative (and possibly commutative)
rearrangement. This does not affect the order in which the argument
forms are evaluated, of course; that order is always left-to-right, as
in all Common Lisp function calls. What is left loose is the order in
which the argument values are processed."
Ooops. Sorry. I was wedged and looking in the wrong place.
"Never mind."
--Guy
∂06-Jan-89 1346 Common-Lisp-mailer commonlisp types
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89 13:46:18 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 306345; 6 Jan 89 15:57:47 EST
Received: from CALVARY.ILA.Dialnet.Symbolics.COM by F.ILA.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 7603; Fri 6-Jan-89 15:33:07 EST
Date: Fri, 6 Jan 89 15:33 EST
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Subject: commonlisp types
To: gls%Think.COM@Riverside.Symbolics.COM, jwz%spice.cs.cmu.edu@Riverside.SCRC.Symbolics.COM,
common-lisp%sail.stanford.edu@Riverside.SCRC.Symbolics.COM
In-Reply-To: <881222151736.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Supersedes: <19890103102924.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-ID: <19890106203322.2.RWK@CALVARY.ILA.Dialnet.Symbolics.COM>
Date: Thu, 22 Dec 88 15:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Fyi, it turns out this rationale doesn't hold as much water as you'd think.
Consider:
(defun bar (x) (symbolp x))
(defun foo (x)
(flet ((bar (y) (integerp y)))
(typep x '(satisfies bar))))
(foo 'x)
The correct answer is T, but I bet a lot of implementations return NIL
in compiled code.
Like the Symbolics system, Boo, Hiss!
In terms of source transformations, this would have to compile the TYPEP
as follows:
(defun foo (x)
(flet ((bar (y) (integerp y)))
(let ((#:G0002 x))
(macrolet ((bar (a) `(funcall (symbol-function 'bar) ,a)))
(bar #:G0002)))))
Which is obviously going to require either a codewalker or a typewalker
to identify either locally defined functions or functions used in the
type expansion to shadow with MACROLET.
So I'm curious. Does any compiler actually get this right? Really,
this is a general problem with any form of source-code rewrites. The
Symbolics compiler does get this right with inlined functions, but I'll
bet it doesn't with some other internal in-lined things that work as
source transformations.
∂06-Jan-89 1346 Common-Lisp-mailer commonlisp types
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89 13:46:18 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 306344; 6 Jan 89 15:56:48 EST
Received: from CALVARY.ILA.Dialnet.Symbolics.COM by F.ILA.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 7601; Fri 6-Jan-89 15:15:53 EST
Date: Fri, 6 Jan 89 15:16 EST
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Subject: commonlisp types
To: Jon L White <jonl%lucid.com@Riverside.SCRC.Symbolics.Com>
cc: common-lisp%sail.stanford.edu@Riverside.SCRC.Symbolics.Com
In-Reply-To: <8901040858.AA01403@bhopal>
Message-ID: <19890106201603.1.RWK@CALVARY.ILA.Dialnet.Symbolics.COM>
Date: Wed, 4 Jan 89 00:58:57 PST
From: Jon L White <jonl@lucid.com>
re: How do you define "valid type specifier"?
Very syntactically. I think its perfectly acceptable to have a set
of combination rules for making "words" in the type-specifier syntax,
even though some such "words" would be gibberish.
The important thing is that base-level types -- those defined in
CLtL -- along with DEFSTRUCT extensions be recognizable. They don't
have the problems that SATISFIES generates, or that a broken user
definition generates (such as your DEFTYPE FOO example).
I'm not saying there's a fundamental problem here, just that there's a choice
to be made, and that writing precise and understandable definitions is
non-trivial. I'd like to encourage you to make YOUR definition explicit for
us, as a starting point.
By the bye, on another note, I haven't seen any implementation that
has the bug Kent wondered about earlier:
(defun bar (x) (symbolp x))
(defun foo (x)
(flet ((bar (y) (integerp y)))
(typep x '(satisfies bar))))
(foo 'x)
The correct answer is T, but I bet a lot of implementations return NIL
in compiled code.
Anyone know of an implementation for which this fails?
Yes, Symbolics. You must have missed my query about any implementations
for which it succeeds! Any implementation which does source-rewriting
to optimize TYPEP has to concern itself with this issue. (The issue is the
same as for doing INLINEing, but Symbolics fails to use the same mechanism for
optimizations as it does for inlining.)
∂06-Jan-89 2112 Common-Lisp-mailer Re: commonlisp types
Received: from cayuga.cs.rochester.edu (CS.ROCHESTER.EDU) by SAIL.Stanford.EDU with TCP; 6 Jan 89 21:11:52 PST
Received: from lesath.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/k) id AA09897; Fri, 6 Jan 89 20:12:20 EST
Received: from loopback by lesath.cs.rochester.edu (3.2/k) id AA09737; Fri, 6 Jan 89 20:12:14 EST
Message-Id: <8901070112.AA09737@lesath.cs.rochester.edu>
To: common-lisp@sail.stanford.edu
Subject: Re: commonlisp types
In-Reply-To: Your message of Fri, 06 Jan 89 15:33:00 -0500.
<19890106203322.2.RWK@CALVARY.ILA.Dialnet.Symbolics.COM>
Date: Fri, 06 Jan 89 20:12:09 -0500
From: quiroz@cs.rochester.edu
: So I'm curious. Does any compiler actually get this right?
KCL. See script at the end of this message.
BTW, our mailer didn't like the address
Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
on the excuse that FUJI.ILA.Dialnet.Symbolics.COM is an unknown host.
Cesar
KCl (Kyoto Common Lisp) June 3, 1987
--- UofR version of September 9, 1988
Loading /u/quiroz/.kclrc
Loading /u/quiroz/work/kcl/defsys/defsys.o
Finished loading /u/quiroz/work/kcl/defsys/defsys.o
Finished loading /u/quiroz/.kclrc
> (defun bar (x) (symbolp x))
bar
> (defun foo (x)
(flet ((bar (y) (integerp y)))
(typep x '(satisfies bar))))
foo
> (foo 'x)
t
>(compile 'bar)
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
bar
>(compile 'foo)
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
foo
>(foo 'x)
t
>
∂07-Jan-89 0054 Common-Lisp-mailer commonlisp types
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jan 89 00:54:42 PST
Received: from LUCID.COM by Riverside.SCRC.Symbolics.COM via INTERNET with SMTP id 306559; 7 Jan 89 03:53:00 EST
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA08351g; Sat, 7 Jan 89 00:50:24 PST
Received: by bhopal id AA02943g; Sat, 7 Jan 89 00:52:38 PST
Date: Sat, 7 Jan 89 00:52:38 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901070852.AA02943@bhopal>
To: RWK@FUJI.ILA.Dialnet.Symbolics.COM
Cc: jonl%lucid.com@Riverside.SCRC.Symbolics.Com,
common-lisp%sail.stanford.edu@Riverside.SCRC.Symbolics.Com
In-Reply-To: Robert W. Kerns's message of Fri, 6 Jan 89 15:16 EST <19890106201603.1.RWK@CALVARY.ILA.Dialnet.Symbolics.COM>
Subject: commonlisp types
re: [TYPE-SPECIFIER-P] I'd like to encourage you to make YOUR definition
explicit for us, as a starting point.
Well, what I can tell you in reasonable terms won't be that helpful. We
simpy hook in to the part of SUBTYPEP that has to resolve these questions,
and "catch" any signals about unrecognized types. For symbols, the
question of a recognized type is fairly easy -- there's a list in CLtL
of some basic types, and then there's more basic types coming from
DEFSTRUCT, and finally there's "recursion" via DEFTYPE. Can you think
of an easier answer for this?
re: Anyone know of an implementation for which this fails?
Yes, Symbolics. You must have missed my query about any implementations
for which it succeeds! Any implementation which does source-rewriting
to optimize TYPEP has to concern itself with this issue. (The issue is the
same as for doing INLINEing, but Symbolics fails to use the same mechanism
for optimizations as it does for inlining.)
Lucid succeeds (and one or two others that I tried). Oddly enough, Lucid
also "fails" to use the same mechanism for compiler optimizers as it does
for INLINEing -- and it gets the optimizations right, but certain cases
of lexical inlining screws wrong.
-- JonL --
∂10-Jan-89 0756 Common-Lisp-mailer Character proposal
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 07:56:38 PST
Date: Mon, 09 Jan 89 19:50:46 PST
From: Thom Linden <baggins@ibm.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890109.195046.baggins@IBM.com>
Subject: Character proposal
The revised proposal should be transmitted fairly soon. Due to this
delay, I won't be asking for a vote unless J13 agrees it is ready.
The content of the scheduled time for characters will be to
review the substantial changes.
I will bring copies to the meeting as well as send over the network.
Regards,
Thom
∂10-Jan-89 0930 Common-Lisp-mailer Re: commonlisp types
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89 09:30:06 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 307284; 10 Jan 89 12:28:11 EST
Date: Mon, 9 Jan 89 21:42 EST
From: Robert W. Kerns <RWK@F.ILA.Dialnet.Symbolics.COM>
Subject: Re: commonlisp types
To: quiroz%cs.rochester.edu@RIVERSIDE.SCRC.SYMBOLICS.COM, common-lisp%sail.stanford.edu@RIVERSIDE.SCRC.SYMBOLICS.COM
In-Reply-To: <8901070112.AA09737@lesath.cs.rochester.edu>
Message-ID: <19890110024213.3.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Fri, 06 Jan 89 20:12:09 -0500
From: quiroz@cs.rochester.edu
: So I'm curious. Does any compiler actually get this right?
KCL. See script at the end of this message.
OK, next question: Does it open-code or otherwise optimize TYPEP, or
just call TYPEP on the list?
If you don't know, I'll check it next time I use KCL (which will be
*after* X3J13).
BTW, our mailer didn't like the address
Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
on the excuse that FUJI.ILA.Dialnet.Symbolics.COM is an unknown host.
"It's not my PLANET, Monkey Boy!"
-- John Wharten (villan from Buckaroo Bonzai)
As a workaround, you can use
RWK%FUJI.ILA.Dialnet.Symbolics.Com@Riverside.SCRC.Symbolics.Com
which is essentially what I have to do to send to you.
Or you can use RWK@AI.AI.MIT.Edu, which forwards to the same place.
∂12-Jan-89 0427 Common-Lisp-mailer Re: commonlisp types
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89 04:27:20 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 307893; 12 Jan 89 06:41:54 EST
Date: Thu, 12 Jan 89 06:09 EST
From: Robert W. Kerns <RWK@F.ILA.Dialnet.Symbolics.COM>
Subject: Re: commonlisp types
To: Robert W. Kerns <RWK@F.ILA.Dialnet.Symbolics.COM>, quiroz%cs.rochester.edu@RIVERSIDE.SCRC.SYMBOLICS.COM,
common-lisp%sail.stanford.edu@RIVERSIDE.SCRC.SYMBOLICS.COM
In-Reply-To: <19890110024213.3.RWK@F.ILA.Dialnet.Symbolics.COM>
Message-ID: <19890112110920.0.RWK@F.ILA.Dialnet.Symbolics.COM>
Date: Mon, 9 Jan 89 21:42 EST
From: Robert W. Kerns <RWK@F.ILA.Dialnet.Symbolics.COM>
BTW, our mailer didn't like the address
Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
on the excuse that FUJI.ILA.Dialnet.Symbolics.COM is an unknown host.
"It's not my PLANET, Monkey Boy!"
-- John Wharten (villan from Buckaroo Bonzai)
Sumimasen, ga... I think that's supposed to be "Wharfin" or something.
∂12-Jan-89 0949 Common-Lisp-mailer Order of "processing" of arguments
Received: from ATHENA.CS.YALE.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 89 09:49:45 PST
Received: by ATHENA.CS.YALE.EDU; Thu, 12 Jan 89 12:49:19 EST
Date: Thu, 12 Jan 89 12:49:19 EST
From: Bruce Krulwich <krulwich-bruce@YALE.ARPA>
Full-Name: Bruce Krulwich
Message-Id: <8901121749.AA18587@ATHENA.CS.YALE.EDU>
Received: by yale-hp-crown (szechuan)
via WIMP-MAIL (Version 1.3/1.5) ; Thu Jan 12 12:51:16
To: Common-Lisp@SAIL.Stanford.EDU
Subject: Order of "processing" of arguments
Newsgroups: arpa.common-lisp
In-Reply-To: <46940@yale-celray.yale.UUCP>
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Michael Greenwald said:
>Actually, CLtL pg 61 says that the arguments and parameters are
>processed in order, from left to right. I don't know if "processed"
>implies "evaluated", but I always assumed (perhaps incorrectly) it did.
Guy Steele replied:
>I interpret this as referring to how the (fully evaluated) arguments
>are processed during lambda-binding, not to the order in which argument
>forms in a function call are evaluated. After all, the arguments referred
>to on page 61 might have come from a list given to APPLY, rather then
>from EVAL on a function call.
This seems vacuous to me. Does this mean that an implementation in which a
procedure entry point knows how many arguments its receiving (through a link
table, for instance, or simply by counting its arguments) and constructs a
REST-arg list before doing the binding of the required args is in violation of
CLtL because it processes the rightmost argument before the leftmost one?? I
hope not.
It seems to me that as long as actuals and formals are matched up correctly
there is no reason for the language specification to specify the order of the
"processing" of the arguments during lambda-binding.
Bruce Krulwich
krulwich@cs.yale.edu
∂12-Jan-89 1245 Common-Lisp-mailer Logical Operations on Numbers
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 12 Jan 89 12:45:18 PST
Received: from vax3.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
id AA00579; Thu, 12 Jan 89 15:46:00 est
Message-Id: <8901122046.AA00579@crash.cs.umass.edu>
Date: Thu, 12 Jan 89 15:31 EST
From: ELIOT@cs.umass.EDU
Subject: Logical Operations on Numbers
To: common-lisp@sail.stanford.EDU
X-Vms-To: IN%"common-lisp@sail.stanford.EDU"
Section 12.7 (pp 220-225) describes CL operations for manipulating
finite sets using integers. Unfortunately there does not seem to
be any predicate to determine if one set is a subset of another
using this representation. 'logtest' serves as an intersection test,
'logbitp' serves as a member test but to determine subset relations
seems to require computing the set difference (with logandc2) and
comparing the result with zero. If the sets are moderately large
(say several hundred elements) this involves expensive bignum operations
that I would like to avoid.
I have also thought of using bitvectors, but the operations on bitvectors
(p 294) only operate on bitvectors of the same length. Furthermore,
the bitvector functions only include bitwise operations, but no subset
test here either.
Isn't SUBSET considered an important set manipulation primitive?
Chris Eliot
University of Massashusetts at Amherst
∂12-Jan-89 1325 Common-Lisp-mailer argument processing
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 12 Jan 89 13:25:08 PST
Received: from vax3.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
id AA00629; Thu, 12 Jan 89 16:25:58 est
Message-Id: <8901122125.AA00629@crash.cs.umass.edu>
Date: Thu, 12 Jan 89 16:19 EST
From: MURRAY@cs.umass.EDU
Subject: argument processing
To: common-lisp@sail.stanford.EDU
X-Vms-To: IN%"common-lisp@sail.stanford.EDU"
Subj: Order of "processing" of arguments
To: Common-Lisp@SAIL.Stanford.EDU
> From: Bruce Krulwich <krulwich-bruce@YALE.ARPA>
> ...
> It seems to me that as long as actuals and formals are matched up correctly
> there is no reason for the language specification to specify the order of the
> "processing" of the arguments during lambda-binding.
The order of processing of lambda-binding is important, because
&optional or &key parameters can have code that is executed if their arguments
are not supplied in a call. By specifying the left-right order of processing,
it defines that any arguments bound "on the left" are accessable to code
executed "on the right".
Kelly Murray
∂12-Jan-89 1331 Common-Lisp-mailer Logical Operations on Numbers
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89 13:31:37 PST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520433; Thu 12-Jan-89 16:29:56 EST
Date: Thu, 12 Jan 89 16:29 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Logical Operations on Numbers
To: ELIOT@cs.umass.EDU, common-lisp@sail.stanford.EDU
In-Reply-To: <8901122046.AA00579@crash.cs.umass.edu>
Message-ID: <19890112212955.5.CASSELS@GROUSE.SCRC.Symbolics.COM>
Date: Thu, 12 Jan 89 15:31 EST
From: ELIOT@cs.umass.EDU
Section 12.7 (pp 220-225) describes CL operations for manipulating
finite sets using integers. Unfortunately there does not seem to
be any predicate to determine if one set is a subset of another
using this representation. 'logtest' serves as an intersection test,
'logbitp' serves as a member test but to determine subset relations
seems to require computing the set difference (with logandc2) and
comparing the result with zero. If the sets are moderately large
(say several hundred elements) this involves expensive bignum operations
that I would like to avoid.
One can imagine a compiler noticing the pattern (LOGTEST .. (LOGNOT ..))
and compiling a call to a special routine which didn't do the explicit
LOGNOT computation. I don't know of any compiler which does this,
though.
I have also thought of using bitvectors, but the operations on bitvectors
(p 294) only operate on bitvectors of the same length.
For vectors, it's not too hard to imagine that the shorter one should be
treated as if it were extended with zeros (presumably at the higher
index end). It's a little harder to decide what to do in the
multidimensional case.
Furthermore,
the bitvector functions only include bitwise operations, but no subset
test here either.
Isn't SUBSET considered an important set manipulation primitive?
Chris Eliot
University of Massashusetts at Amherst
Symbolics Common Lisp defines:
SCL:BIT-VECTOR-SUBSET-P - Function (BIT-VECTOR-1 BIT-VECTOR-2 &key (:START1 0) :END1 (:START2 0) :END2)
;; BIT-VECTOR-1 is a subset of BIT-VECTOR-2
SCL:BIT-VECTOR-POSITION - Function (BIT BIT-VECTOR &key (:START 0) :END)
;; equivalent to (POSITION BIT BIT-VECTOR :START START :END END)
SCL:BIT-VECTOR-ZERO-P - Function (BIT-VECTOR &key (:START 0) :END)
SCL:BIT-VECTOR-EQUAL - Function (BIT-VECTOR-1 BIT-VECTOR-2 &key (:START1 0) :END1 (:START2 0) :END2)
;; equivalent to (EQUAL (SUBSEQ BIT-VECTOR-1 :START START1 :END END1)
;; (SUBSEQ BIT-VECTOR-2 :START START2 :END END2))
SCL:BIT-VECTOR-DISJOINT-P - Function (BIT-VECTOR-1 BIT-VECTOR-2 &key (:START1 0) :END1 (:START2 0) :END2)
SCL:BIT-VECTOR-CARDINALITY - Function (BIT-VECTOR &key (:START 0) :END)
;; counts the "1" bits
At the present time, -SUBSET-P, -EQUAL, and -DISJOINT-P all return NIL
if the vectors have different lengths.
A more CL-consistent way of doing cardinality is probably by analogy
with the COUNT function:
BIT-VECTOR-COUNT - Function (BIT BIT-VECTOR &key (:START 0) :END)
;; equivalent to (COUNT BIT BIT-VECTOR :START START :END END)
∂12-Jan-89 1956 Common-Lisp-mailer cs proposal part 1
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 19:54:57 PST
Date: Thu, 12 Jan 89 13:33:25 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890112.133325.baggins@almvma>
Subject: cs proposal part 1
\documentstyle{report} % Specifies the document style.
\pagestyle{headings}
\title{\bf
Extensions to Common LISP to Support International
Character Sets}
\author{
Michael Beckerle\thanks{Gold Hill Computers} \and
Paul Beiser\thanks{Hewlett-Packard} \and
Robert Kerns\thanks{Independent consultant} \and
Kevin Layer\thanks{Franz, Inc.} \and
Thom Linden\thanks{IBM Research, Subcommittee Chair} \and
Larry Masinter\thanks{Xerox Research} \and
David Unietis\thanks{Lucid, Inc.}
}
\date{January 1, 1989} % Deleting this command produces today's date.
\begin{document}
\maketitle % Produces the title.
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}
\tableofcontents
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newfont{\cltxt}{cmr10}
\newfont{\clkwd}{cmtt10}
\newcommand{\apostrophe}{\clkwd '}
\newcommand{\bq}{\clkwd\symbol{'22}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Introduction}
This is a proposal to the X3 J13 committee
for both extending and modifying the Common LISP
language definition to provide a standard basis for Common LISP
support of the variety of characters used to represent the
native languages of the international community.
This proposal was created by the Character Subcommittee of X3 J13.
We would like to acknowledge discussions with T. Yuasa and other
members of the JIS Technical Working Group,
comments from members of X3 J13,
and the proposals \cite{ida87},
\cite{linden87}, \cite{kerns87}, and \cite{kurokawa88} for
providing the motivation and direction for these extensions.
As all these documents and discussions were created
expressly for LISP standardization usage,
we have borrowed freely from their ideas as well as the texts
themselves.
This document is separated into three parts. The first part explains the
major language changes and their motivations. While intended as
commentary to a general audience, and not explicitly as
part of the standard document, the X3 J13 editor may
include sections at her/his discretion. The second part,
Appendix A, provides
the page by page set of editorial changes to \cite{steele84}.
The final part, Appendix B, contains language elements deleted
from \cite{steele84} which we view as important from a compatibility
viewpoint but consider deprecated Common LISP features.
\section{Objectives}
The major objectives of this proposal are:
\begin{itemize}
\item To provide a consistent, well-defined scheme allowing support
of both very large character sets and multiple character sets.
\footnote{The distinction between the terms {\em character repertoire}
and {\em coded character set} is made later. The usage
of the term {\em character set},
avoided after this introduction, encompasses both terms.}
Many software applications are intended for international use, or
have requirements for incorporation of language elements of multiple
native languages within a single application.
Also, many applications require specialized languages including,
for example, scientific and typesetting symbols.
In order
to ensure some portability of these applications, data expressed in
a mixture of these
languages must be treated uniformly by the
software language.
All character and string manipulations should operate uniformly,
regardless of the character set(s) of the character objects.
This applies to array indexing, readtable definitions, read
symbol construction and I/O operations.
\item To ensure efficient performance of string and character
operations.
Many native
languages, such as Japanese and Chinese, use character
sets which contain more characters than the Latin alphabet.
Supporting larger sized character sets frequently means employing
larger data fields to uniquely encode each character.
Common LISP implementations using
larger sized character sets can
incur performance penalties in terms
of space, time, or both.
The use of large and/or multiple character sets by an
implementation
implies the need for a more complex character type representation.
Given a more complex character representation, the efficiency
of language operations on characters (e.g. string operations)
could be affected.
\item To assure forward compatibility of the proposed model
and definition with existing Common LISP implementations.
Developers should not be required to re-write large amounts of either
LISP code or data representations in order to apply the proposed
changes to existing implementations.
The proposed changes should provide an easy
portability path for existing code to many possible implementations.
\end{itemize}
There are a number of issues, some under the general rubric of
internationalization, which this proposal does {\em not} cover.
Among these issues are:
\begin{itemize}
\item Time and date formats
\item Monetary formats
\item Numeric punctuation
\item Fonts
\item Lexicographic orderings
\item Right-to-left and bidirectional languages
\end{itemize}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Overview}
We use several terms within this document which
are new in the context of Common LISP.
Definitions for the following prominent
terms are provided for the reader's convenience.
A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font. This
corresponds to the mathematical notion of a {\em set}
\footnote{We avoid the term {\em character set} as it has been
(over)used in the context of character repertoire as well
as in the context of coded character set.}.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique label, a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
There are numerous internationally standardized coded character
sets; for example, \cite{iso8859/1} and \cite{iso646}.
A character may be included in one or more character repertoires.
Similarly, a character may be included in one or more
coded character sets. For example, the Latin letter "A" is contained
in the coded character set standards: ISO 8859/1, ISO 8859/2,
ISO 6937/2, and others.
Common LISP
characters are partitioned into a unique collection of
repertoires called {\em
Character Registries}. That is, each character is included
in one and only one Character Registry. The label identifying
each character within a Character Registry is a unique numerical value
referred to as the {\em character index}.
In Common LISP a {\em character} data object is identified by its
{\em character code}, a unique numerical code.
Each character code is composed from
a Character Registry
shared by all characters of a particular Registry,
and a character index, a numerical value which
is unique within the Character Registry.
Character data objects which are classified as {\em graphic},
or displayable, are each associated with a {\em glyph}. The
glyph is the visual representation of the character.
The primary purpose of introducing these terms is to provide a
consistent naming to Common LISP concepts which are related
to those found in ISO standardization of coded
character sets.
\footnote{The bibliography includes several relevant ISO
coded character set standards.}
They also serve as a demarkation between these
standardization activities. For example, while Common LISP is free to
define unique repertoires and facilities to manipulate them, it should
not define coded character sets.
A secondary purpose is to detach the language specification from
underlying hardware representation. From a language
specification viewpoint it is inconsequential whether
characters occupy one or more (8-bit) bytes or whether
a Common LISP implementation's
internal representation for characters is distinct from or identical
to any given external representation (for example, a text interchange
representation \cite{iso6937/2}).
We specifically do not propose any standard coded character sets.
%----------------------------------------------------------------------
\section{Character Identity}
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers. That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
Character codes are composed from a Character Registry and a
character index. The convention by which a character index and
Character Registry compose a character code is implementation
dependent.
It is important to separate the notion of glyph from the notion of
character data object when defining a scheme under which issues of
identity can be rigorously decided by a computer language. Glyphs are
the visual aspects of characters, writable on surfaces, and sometimes
called 'graphics'. A language specification valid for more than a
narrow range of systems can only make assumptions about the existence
of {\em abstract} glyphs (for example, the Latin letter A) and not about
glyph variants (for example, the italicized Latin letter {\em A})
or characteristics of display devices. Thus, a key element of this
proposal is the removal of the {\em font} and {\em bits}
attributes from the language specification.
One ramification is that the distinction between {\clkwd string-char}
and {\clkwd character} is eliminated. {\bf All} characters can be
inserted into (type compatible) strings.
In addition, all functions
dealing with the {\em bits} and {\em font} attributes are either
removed or modified by this proposal.
A second ramification is the introduction of new functions to
compose and decompose character objects.
The {\clkwd characterp} predicate is extended to
support testing
membership of a character in a given Character Registry.
\footnote{
For example,
testing membership in the Japanese Katakana Character Registry.
}
Also, a global variable {\clkwd *all-registry-names*} is added to
support application determination of supported Character Registries.
A third ramification is that I/O functions must be modified to manage
the interaction between the Common LISP treatment of characters and
the external environment.
The definition in \cite{steele84} of semi-standard characters has
been eliminated. This is replaced by a more uniform approach
with introduction of the Control Character
Registry (see below).
%----------------------------------------------------------------------
\section{Character Repertoires and Registries}
A Common LISP program must be able to compose and decompose
characters in a portable uniform manner, independent of any
underlying representation. One possible composition is by
the pair $<$ coded character set standard, decimal representation $>$
\footnote{This syntax is for illustration only and is not being
proposed.}.
Thus, for example, one might compose the Latin 'A' with the pair
$<$ "ISO8859/2-1987ccs", 65 $>$,
$<$ "ISO8859/6-1987ccs", 65 $>$, or
$<$ "ISO646-1983ccs", 65 $>$, etc.. The difficulty here is two-fold.
First, there are several ways to compose the same character and
second, there may be multiple answers to
the question: {\em To what coded character set
does character object x belong?}.\footnote{Even
worse, the answer might change yearly.}
The identical problems occur if the pair
$<$ character repertoire standard, decimal representation $>$ is used.
\footnote{Existing repertoires seem to be defined exclusively
in the context of coded character sets and not as standards
in their own right.}
The concept of Character Registry is introduced by this proposal
to resolve the problem of character composition and decomposition.
Each character is universally defined by the
pair $<$ Character Registry name, character index $>$. For this
to be a portable definition, it must have a standard meaning.
Thus this
proposal relies on a {\em Character Registry Standard}.
There is no existing Character Registry Standard.
Until such an ANSI or ISO standard exists, Common LISP
defines the {\em Common LISP Character Registry Standard}.
\footnote{It is the intention of X3 J13 to promote and adopt
an eventual ANSI or ISO Character Registry Standard. In particular, we
acknowledge that X3 J13 is {\em not} the appropriate forum to
define the standard. We believe
it is a required component of all programming languages
providing support for international characters.}
Common LISP defines the following Character Registries:
\footnote{In the interest of brevity, this document will
define only a partial list of
the Character Registry names. A subsequent
document will define the complete Common LISP Character Registry
Standard including the effect of the character predicates
{\em alpha-char-p},
{\em lower-case-p}, etc..}
\footnote{
Character Registry names are strings formed from the Common LISP
{\clkwd standard-p} characters. Within registry names, alphabetic
case is ignored.}
\begin{itemize}
\item Arabic
\item Armenian
\item Bo-po-mo-fo
\item Control
\item Cyrillic
\item Georgian
\item Greek
\item Hangul
\item Hebrew
\item Hiragana
\item Japanese-Punctuation
\item Kanji-JIS-Level-1
\item Kanji-JIS-Level-2
\item Kanji-Gaiji
\item Katakana
\item Latin
\item Latin-Punctuation
\item Mathematical
\item Pattern
\item Phonetic
\item Technical
\end{itemize}
The Common LISP Character Registry Standard is fixed;
an implementation
may not extend the set of characters within any Common LISP
Character Registry.
An implementation may provide support for all or part of any Common LISP
Character Registry
and may provide new character registries which include characters
having unique semantics (i.e. not defined in any other
implementation-defined character registry or Common LISP Character
Registry). Implementation registries must be uniquely
named using only {\clkwd standard-p} characters. In addition,
the repertoire names {\em base} and {\em standard} have
reserved Common LISP usage.
An implementation must document the registries it supports.
For each registry supported,
an implementation must define individual characters supported
including at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions.
\item $<$ Common LISP
Character Registry name, character index $>$ pair if one exists
otherwise $<$ implementation-defined
character registry name, character index $>$ pair.
\item Reader Canonicalization.
\item Position in total ordering.
The partial ordering of the Standard alphanumeric
characters must be preserved.
\item Effect of character predicates.
In particular,
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd standard-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O. In particular, the
coded character set standards
\footnote{For example, "ISO8859/1-1987ccs".} and
external encoding schemes
\footnote{For example, {\em "Xerox System Integration Character
Code Standard"}\cite{xerox87}.}
which are supported must be specified.
\end{itemize}
The
intent of the provision for multiple character registries
is that native language glyphs (with associated digits and
punctuation)
\footnote{For example, the glyphs on the keycaps of a particular
terminal, or any other glyph sets with a common use in graphics or
symbolic communication.
}
should each be mapped by the I/O interface
into registries inside
Common LISP, all the members of which
share a common registry name.
Which glyph sets are supported by the overall computing system, the
details of the mapping of
glyphs to character codes, and any implementation unique character
registry names used, are left unspecified by Common LISP.
The diversity of glyph sets and coded character
set conventions in use worldwide and the desirability
of allowing Common LISP to manipulate symbolic elements from many
languages, perhaps simultaneously, mandate such a flexible approach.
%----------------------------------------------------------------------
\section{Hierarchy of Types}
Providing support for extensive character repertoires may
impact Common LISP implementation performance in terms
of space, time, or both.
\footnote{This does not apply to all implementations.
Unique hardware support and user community requirements must
be taken into consideration.}
In particular, many existing
implementations support variants of the ISO 8859/1 standard.
Supporting large
repertoires argues for a multi-byte internal representation
for each character, even if an application primarily (or exclusively)
uses the ISO 8859/1 characters.
This proposal extends the definition of the character and string
type hierarchy to include specialized subtypes
of character and string. An implementation is free to associate
compact internal representation tailored to each subtype.
The {\clkwd string} type specifier, when used as a
declaration (for example, in {\clkwd make-sequence})
is defined to mean the most general string subtype supported
by the implementation. This definition emphasizes portability
of existing Common LISP applications to international
character environments over performance. Applications emphasizing
efficiency of text processing in non-international environments
will require some modification to utilize subtypes with
compact internal representations.
It has been suggested that either a single type is
sufficient to support international characters,
or that a hierarchy of types could be used, in a manner
transparent to the user. A desire to provide flexibility which
encourages implementations to support international
characters without compromising application efficiency
led us to accept the need for more than one type.
We believe that these choices reflect a minimal
modification of this aspect of the type system, and that
exposing the types for string and character construction while
requiring uniform treatment for characters otherwise
is the most reasonable approach.
\subsection{Character Type}
The following type specifier is added as a subtype
of {\clkwd character}.
\begin{itemize}
\item {\clkwd base-character}
\end{itemize}
An implementation may support additional subtypes of {\clkwd character}
which may or may not be supertypes of {\clkwd base-character}.
In addition, an implementation may define {\clkwd base-character}
as equivalent to {\clkwd character}.
Characters of type {\clkwd base-character} are referred to as
{\em base characters}. Characters of type {\clkwd
(and character (not base-character))}
are referred to as {\em extended characters}.
The base characters are
distinguished in the following respects:
\begin{itemize}
\item
The standard characters are a subrepertoire of the base characters.
\item
Only members of the base character repertoire
can be elements of a base string.
\item
The base characters are, in general, the default characters for I/O
operations.
\end{itemize}
No upper bound is specified for the number of glyphs in the base
character repertoire--that
is implementation dependent. The lower bound is 96, the
number of standard characters defined for Common LISP.
\footnote{Or, in contrast, the base repertoire may include all
the Common LISP Character Registries.}
The distinction of base characters is largely a pragmatic
choice. It permits efficient handling of common situations, is
in some sense privileged for host system I/O, and can serve as an
intermediate basis for portability, less general than the standard
characters, but possibly more useful across a narrower range of
implementations.
Many computers have some "base" character representation which
is a function of hardware instructions for dealing with characters,
as well as the organization of the file system. The base character
representation is likely to be the smallest transaction unit permitted
for text file and terminal I/O operations. On a system with a record
based I/O paradigm, the base character representation is likely to
be the smallest record quantum. On many computer systems,
this representation is a byte.
However, there are often multiple
coded character sets supportable on a
computer, through the use of special display and entry hardware, which
are varying interpretations of the basic system character
representation. For example, ISO 8859/1 and ISO 6937/2 are two
different interpretations of the same 1-byte code representations.
Many countries have their own glyph-to-code mappings for 1-byte
character codes addressing the special requirements of national
languages. Differentiating between these, without reference to
display hardware, is a matter of convention, since they all use the
same set of code representations. When a single byte is not enough,
two or more bytes are sometimes used for character encoding. This
makes character handling even more difficult on machines where the
natural representation size is a byte, since not only is the semantic
value of a character code a matter of convention, which may vary
within the same computing system, but so is the identification of a
set of bits as a complete character code.
It is the intention of this proposal that the base characters of
Common LISP
be the natural characters of the host system: its composition
should be
determined by the code capacity of the natural file system and I/O
transaction representations, and its assumed display glyphs should be
those of the terminals most commonly employed.
There are several advantages to this scheme. Internal representation
of strings of just base characters can be more compact than
strings including extended characters.
Source programs are likely to consist predominantly of base characters
since the standard characters are a subset of the base character
repertoire. Parsing of pure base character text
can be more efficient than parsing of text including
extended characters.
I/O can be performed more simply
with base characters.
The standard characters are the 96 characters used in the Common LISP
definition {\bf or their equivalents}.
This was the Common LISP \cite{steele84} definition, but
{\em equivalents} is a vague term.
The standard characters are not defined by their glyphs, but by their
roles within the language. There are two aspects to the roles of the
standard characters: one is their role in reader and format control
string syntax; the second is their role as components of the names of
all Common LISP
functions, macros, constants, and global variables. As
long as an implementation chooses 96 glyphs
and treats those 96 in a manner consistent with
the language's specification for the standard characters (e.g.
the naming of functions), it doesn't matter what glyphs the I/O
hardware uses to represent those characters: they are the standard
characters. Any program or
data text written wholly in those characters
is portable through simple code conversion.
\footnote{For example, the currency glyph, \$ , might be replaced
uniformly by the currency glyph available on a particular display.}
Additional
mechanisms, such as in \cite{linden87}, which support establishment of
equivalency between otherwise distinct characters are not excluded by
this proposal.
\footnote{We believe this is an important issue but it requires
additional implementation experience. We also encourage
new proposals from JIS and ISO LISP Working Groups on this issue.}
\subsection{String Type}
The {\clkwd string} type
is defined as
a vector of characters. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype of character. The following string
subtypes are
distinguished with standardized names: {\clkwd base-string},
{\clkwd general-string}, {\clkwd simple-base-string}, and
{\clkwd simple-general-string}.
All strings which are not base strings
are referred to as {\em extended strings}.
A base string can only contain base characters. A
{\clkwd general-string}
can contain any implementation supported base or extended characters,
in any mixture.
\footnote{This type might be more appropriately named
{\clkwd most-general-string}. {\clkwd general-string} was
subjectively judged to be less offensive.}
All Common LISP functions defined to operate on strings treat
base and extended strings uniformly with the following
caveat: for any function which inserts a character into a string, it
is an error to insert an extended character
into a base string.
\footnote{An implementation may, optionally, provide automatic
coersion to an extended string.}
An implementation may support string subtypes more general
than {\clkwd base-string} but more specialized than
{\clkwd general-string}.
For example, a hypothetical
implementation supporting Arabic and Cyrillic Character Registries
might provide:
\begin{itemize}
\item {\clkwd general-string} -- may contain Arabic, Cyrillic or
base characters in any mixture.
\item {\clkwd region-specialized-string} -- may contain installation
selected repertoire (Arabic/Cyrillic) or base characters in any
mixture.
\item {\clkwd base-string} -- may contain base characters
\end{itemize}
Though, clearly, portability of applications using
{\clkwd region-specialized-string} is limited, a performance
advantage might argue for its use.
\footnote{{\clkwd region-specialized-string} is used here for
illustration only; it is not being proposed as a standardized
string subtype.}
Alternatively,
an implementation
supporting a large base character repertoire
including, say, Japanese Character Registries may define
{\clkwd base-character}
as equivalent to {\clkwd character}.
We expect that applications sensitive to the performance
of character handling in some host environments will
utilize the string subtypes to provide performance
improvement. Applications with emphasis on international
portability will likely utilize only {\clkwd general-string}s.
The {\clkwd coerce} function is extended to
allow for explicit coercion between base strings and extended strings.
During reader
construction of symbols, if all the characters
in the symbol's name are of type {\clkwd base-character},
then the name of the symbol may be stored as a base string.
Otherwise it will be stored as an extended string.
The base string type allows for more compact representation of strings
of base characters, which are likely to predominate in any system.
Note that in any particular implementation the base characters
need not be the
most compactly representable, since others might have
a smaller repertoire.
However, in most implementations base strings are
likely to be more space efficient than extended strings.
%----------------------------------------------------------------------
\section{Streams and System I/O}
A lot of the work of ensuring that a
Common LISP implementation operates correctly in a
multiple coded character set environment must be performed by
the I/O interface.
The system I/O interface, abstracted in
Common LISP as streams, is responsible
for ensuring that text input from outside LISP is properly mapped
into character objects internally, and that the inverse mapping
is performed on output. It is beyond the scope of a language
definition to specify the details of this operation, but options
are specified which allow runtime indication from the user as to
what coded character sets a stream uses, and how the mappings
should be done. It is expected that implementations will provide
reasonable defaults and invocation options to accommodate desired use
at an installation.
One keyword argument is proposed as an addition to {\clkwd open}:
\begin{itemize}
\item {\clkwd :external-code-format}
whose value would be:
\begin{itemize}
\item
A name or list indicating an implementation recognized scheme for
representing 1 or more coded character sets.
\footnote{
For example, the so/si convention used by IBM on 370
machines could be selected by a list including
the name {\em "ibm-shift-delimited"}.
The run-encoding convention defined by XEROX could be
selected by {\em "xerox-run-encoded"}.
The convention based on
ASCII which uses leading bit patterns to distinguish two-byte codes
from one-byte codes could be selected by
{\em "ascii-high-byte-delimited"}.
}
As many coded character set names must be provided as the
implementation requires for that external coding convention.
\footnote{
For example, if {\em "ibm-shift-delimited"} were the
{\clkwd :external-code-format} argument, two
coded character set specifiers would have to be provided.
}
\end{itemize}
\end{itemize}
These arguments are provided for input, output, and
bidirectional streams.
It is an error to try to write a character other than a
member of the specified coded character sets
to a stream. (This excludes the
\#$\backslash${\clkwd Newline} character.
Implementations must provide appropriate line division behavior
for all character streams.)
An implementation supporting multiple coded character sets
must allow for the external
representation of characters to be separately (and perhaps
multiply) specified to {\clkwd open},
since there can be circumstances under
which more than one external representation for characters
is in use, or more than one coded character set
is mixed together in an
external representation convention.
In addition to supporting conversion at the system interface, the
language must allow user programs to determine how much space data
objects will require when output in whichever external representations
are available.
The new function {\clkwd external-width}
takes a character
or string object as its required argument. It also takes an optional
{\em output-stream}.
It returns the number of host system character
representation quantum units
\footnote{
Same as the storage width of a base character, usually a byte.
}
required to externally store that object, using the
representation convention associated with the stream.
If the object cannot be represented in
that convention, the function returns {\clkwd nil}.
This function is necessary
to determine if strings can be written to fixed length
fields in databases or terminal screen templates. Note that this
function does not
address the problem of calculating
screen width of strings printed in proportional fonts.
\footnote{
The X3 J13 proposal STREAM-INFO: ONE-DIMENSIONAL-FUNCTIONS
modified to include these semantics is an
acceptable alternative to the {\clkwd external-width} function
proposed here.}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
∂12-Jan-89 1959 Common-Lisp-mailer cs proposal
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 19:59:21 PST
Date: Thu, 12 Jan 89 13:36:53 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890112.133653.baggins@almvma>
Subject: cs proposal
I've just sent out two messages containing the latest character
proposal (no DRAFT this time). We will only vote on this at
Hawaii if the full J13 agrees otherwise (which I expect)
a network ballot will be sent right after Hawaii.
Aloha,
Thom
∂12-Jan-89 2000 Common-Lisp-mailer cs proposal
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 19:59:33 PST
Date: Thu, 12 Jan 89 16:53:24 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890112.165324.baggins@almvma>
Subject: cs proposal
Hopefully the character proposal covers all the varied comments
we received previously. Thanks again to everyone for the constructive
criticism. In particular, I wish to express our thanks to
Yuasa-san, Kurokawa-san and the JIS Lisp committee.
Regards,
Thom
∂12-Jan-89 2341 Common-Lisp-mailer cs proposal part 2 of 3
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 23:40:00 PST
Date: Thu, 12 Jan 89 22:16:40 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890112.221640.baggins@almvma>
Subject: cs proposal part 2 of 3
%----------------------------------------------------------------------
% split into three parts this time as mailer had problems
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newcommand{\edithead}{\begin{tabular}{l p{3.95in}}
\multicolumn{2}{l} }
\newcommand{\csdag}{\bf$\Rightarrow$\ddag}
\newcommand{\editstart}{}
\newcommand{\editend}{\\ & \end{tabular}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\appendix
\chapter{Editorial Modifications to CLtL}
The following sections specify the editorial changes needed in
CLtL to support the proposal. Section/subsection numbers and titles
match those found in \cite{steele84}. The notation
{\csdag x (pn, function)} denotes a reference to paragraph x within the
subsection (we count each individual example or metastatement
as 1 paragraph of text). Also, {\bf (pn, function)}, or simply
{\bf (pn)} is included as an additional
aid to the reader indicating the page number and function modified.
When an entire paragraph is deleted,
the first few words of the paragraph is noted.
If a section or paragraph of CLtL is {\em not} referenced,
no editorial changes are required to support this proposal.
\footnote{This may be an over optimistic statement since the changes
are fairly pervasive. The editor should take the sense of
Chapter 1 into account in resolving any discrepancies.}
%----------------------------------------------------------------------
\setcounter{section}{1}
\section{Data Types} % 2
%----------------------------------------------------------------------
\edithead {\csdag 8 (p12)}
\editstart
\\ \bf replace &
\cltxt
provides for a
rich character set, including ways to represent characters of various
type styles.
\\ \bf with &
\cltxt
provides support for international language characters as well
as characters used in specialized arenas, eg. mathematics.
\editend
\setcounter{subsection}{1}
\subsection{Characters} % 2.2.
\edithead {\csdag 1 (p20)}
\editstart
\\ \bf replace &
\cltxt
Characters are represented as data objects of type {\clkwd character}.
There are two subtypes of interest, called
{\clkwd standard-char} and {\clkwd string-char}.
\\ \bf with &
\cltxt
Characters are represented as data objects of type
{\clkwd character}.
\editend
\\
\edithead {\csdag 2 (p20)}
\editstart
\\ \bf replace &
\cltxt
This works well enough for printing characters. Non-printing
characters
\\ \bf with &
\cltxt
This works well enough for graphic characters. Non-graphic
characters
\editend
\subsubsection{Standard Characters} % 2.2.1.
\edithead {\csdag 0 section heading (p20)}
\editstart
\\ \bf replace &
\cltxt
Standard Characters
\\ \bf with &
\cltxt
Base Characters
\editend
\\
\edithead {\csdag 1 before (p20)}
\editstart
\\ \bf insert &
\cltxt
A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique label, a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
\\ &
Many computers have some "base" coded character set
(often a variant of ISO646-1983)
which is a function
of hardware instructions for dealing with characters, as well as
the organization of
the file system. This base character representation is likely
to be the smallest
transaction unit permitted for text stream I/O operations.
\\ &
The {\em base character repertoire} is used to refer to
the collection of characters represented by
the base coded character set. Common LISP does
not define the base
character encoding
but does require all implementations to support a "standard"
{\em subrepertoire} of the base character
repertoire.
\editend
\\
\edithead {\csdag 1 before (p20)}
\editstart
\\ \bf insert &
\cltxt
The {\clkwd base-character} type is defined as a subtype of
{\clkwd character}. A {\clkwd base-character}
object can contain any member of the base character repertoire.
Objects of type
{\clkwd (and character (not base-character))} are referred to
as {\em extended characters}.
\editend
\\
\edithead {\csdag 1 (p20)}
\editstart
\\ \bf delete &
\cltxt
Common LISP defines a "standard character set" ...
\editend
\\
\edithead {\csdag 1 (P20)}
\editstart
\\ \bf new &
\cltxt
As a subset of the base character repertoire,
Common LISP defines a standard character
subrepertoire for two purposes.
Common LISP programs that are written in the
standard character subrepertoire
can be read by any Common LISP implementation; and Common LISP
programs
that use only standard characters as data objects are most likely
to be portable.
The standard characters are not defined by their glyphs, but by their
roles within
the language. There are two aspects to the roles of the
standard characters:
one is their role in reader and format control
string syntax; the second is their role as
components of the names of all Common LISP
functions, macros, constants, and global
variables. As long as an implementation chooses 96 glyphs
and treats those 96 in a manner
consistent with the language's specification for the standard characters
(for example,
the naming of functions),
it doesn't matter what glyphs the I/O
hardware uses to
represent those characters: they are
the standard characters. Any program or
data text written wholly
in those characters
is portable through simple code conversion.
The Common LISP
standard character subrepertoire consists of
a newline \#$\backslash${\clkwd Newline}, the
graphic space character \#$\backslash${\clkwd Space},
and the following additional
ninety-four graphic characters or their equivalents:
\editend
\\
\edithead {\csdag 2 (p21)}
\editstart
\\ \bf delete &
\cltxt
! " \# ...
\editend
\\
\edithead {\csdag 2 new (p21)}
\editstart
\\ &
{\bf Common LISP Standard Character Subrepertoire}
\editend
\footnote{\cltxt \#$\backslash${\clkwd Space}
and \#$\backslash${\clkwd Newline} are omitted.
graphic labels and descriptions are from ISO 6937/2.
The first letter of the graphic label categorizes the
character as follows: L - Latin, N - Numeric, S - Special
.}
\\
{\small \begin{tabular}{||l|c|l||l|c|l||} \hline
ID & Glyph & Name or description
& ID & Glyph & Name or description
\\ \hline
LA01 & a & small a
& ND01 & 1 & digit 1
\\ \hline
LA02 & A & capital A
& ND02 & 2 & digit 2
\\ \hline
LB01 & b & small b
& ND03 & 3 & digit 3
\\ \hline
LB02 & B & capital B
& ND04 & 4 & digit 4
\\ \hline
LC01 & c & small c
& ND05 & 5 & digit 5
\\ \hline
LC02 & C & capital C
& ND06 & 6 & digit 6
\\ \hline
LD01 & d & small d
& ND07 & 7 & digit 7
\\ \hline
LD02 & D & capital D
& ND08 & 8 & digit 8
\\ \hline
LE01 & e & small e
& ND09 & 9 & digit 9
\\ \hline
LE02 & E & capital E
& ND10 & 0 & digit 0
\\ \hline
LF01 & f & small f
& SC03 & \$ & dollar sign
\\ \hline
LF02 & F & capital F
& SP02 & ! & exclamation mark
\\ \hline
LG01 & g & small g
& SP04 & " & quotation mark
\\ \hline
LG02 & G & capital G
& SP05 & \apostrophe & apostrophe
\\ \hline
LH01 & h & small h
& SP06 & ( & left parenthesis
\\ \hline
LH02 & H & capital H
& SP07 & ) & right parenthesis
\\ \hline
LI01 & i & small i
& SP08 & , & comma
\\ \hline
LI02 & I & capital I
& SP09 & \_ & low line
\\ \hline
LJ01 & j & small j
& SP10 & - & hyphen or minus sign
\\ \hline
LJ02 & J & capital J
& SP11 & . & full stop, period
\\ \hline
LK01 & k & small k
& SP12 & / & solidus
\\ \hline
LK02 & K & capital K
& SP13 & : & colon
\\ \hline
LL01 & l & small l
& SP14 & ; & semicolon
\\ \hline
LL02 & L & capital L
& SP15 & ? & question mark
\\ \hline
LM01 & m & small m
& SA01 & + & plus sign
\\ \hline
LM02 & M & capital M
& SA03 & $<$ & less-than sign
\\ \hline
LN01 & n & small n
& SA04 & = & equals sign
\\ \hline
LN02 & N & capital N
& SA05 & $>$ & greater-than sign
\\ \hline
LO01 & o & small o
& SM01 & \# & number sign
\\ \hline
LO02 & O & capital O
& SM02 & \% & percent sign
\\ \hline
LP01 & p & small p
& SM03 & \& & ampersand
\\ \hline
LP02 & P & capital P
& SM04 & * & asterisk
\\ \hline
LQ01 & q & small q
& SM05 & @ & commercial at
\\ \hline
LQ02 & Q & capital Q
& SM06 & [ & left square bracket
\\ \hline
LR01 & r & small r
& SM07 & $\backslash$ & reverse solidus
\\ \hline
LR02 & R & capital R
& SM08 & ] & right square bracket
\\ \hline
LS01 & s & small s
& SM11 & \{ & left curly bracket
\\ \hline
LS02 & S & capital S
& SM13 & $|$ & vertical bar
\\ \hline
LT01 & t & small t
& SM14 & \} & right curly bracket
\\ \hline
LT02 & T & capital T
& SD13 & \bq & grave accent
\\ \hline
LU01 & u & small u
& SD15 & $\hat{ }$ & circumflex accent
\\ \hline
LU02 & U & capital U
& SD19 & $\tilde{ }$ & tilde
\\ \hline
LV01 & v & small v
& & &
\\ \hline
LV02 & V & capital V
& & &
\\ \hline
LW01 & w & small w
& & &
\\ \hline
LW02 & W & capital W
& & &
\\ \hline
LX01 & x & small x
& & &
\\ \hline
LX02 & X & capital X
& & &
\\ \hline
LY01 & y & small y
& & &
\\ \hline
LY02 & Y & capital Y
& & &
\\ \hline
LZ01 & z & small z
& & &
\\ \hline
LZ02 & Z & capital Z
& & &
\\
\hline
\end{tabular} }
\\
\edithead {\csdag 3 (p21)}
\editstart
\\ \bf delete &
\cltxt
@ A B C...
\editend
\\
\edithead {\csdag 4 (p21)}
\editstart
\\ \bf delete &
\cltxt
\bq a b c...
\editend
\\
\edithead {\csdag 5 (p21)}
\editstart
\\ \bf delete &
\cltxt
The Common LISP Standard character set is apparently ...
\editend
\\
\edithead {\csdag 6 (p21)}
\editstart
\\ \bf replace &
\cltxt
Of the ninety-four non-blank printing characters
\\ \bf with &
\cltxt
Of the ninety-five graphic characters
\editend
\\
\edithead {\csdag 9 (p21)}
\editstart
\\ \bf delete &
\cltxt
The following characters are called ...
\editend
\\
\edithead {\csdag 10 (p21)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd \#$\backslash$Backspace \#$\backslash$Tab } ...
\editend
\\
\edithead {\csdag 11 (p21)}
\editstart
\\ \bf delete &
\cltxt
Not all implementations of Common ...
\editend
\subsubsection{Line Divisions} % 2.2.2.
\edithead {\csdag 6 (p22)}
\editstart
\\ \bf replace &
\cltxt
a two-character sequence, such as
{\clkwd \#$\backslash$Return } and then
{\clkwd \#$\backslash$Newline },
is not acceptable,
\\ \bf with &
\cltxt
a two-character sequence is not acceptable,
\editend
\\
\edithead {\csdag 8 (p22)}
\editstart
\\ \bf delete &
\cltxt
Implementation note: If an implementation uses ...
\editend
\subsubsection{Non-standard Characters} % 2.2.3.
\edithead {\csdag delete entire section (p23)}
\editstart
\editend
\subsubsection{Character Attributes} % 2.2.4.
\edithead {\csdag 0 section heading (p23)}
\editstart
\\ \bf replace &
\cltxt
Character Attributes
\\ \bf with &
\cltxt
Character Identity
\editend
\\
\edithead {\csdag 1 through 8 (p23)}
\editstart
\\ \bf delete all paragraphs&
\cltxt
Every object of type {\clkwd character} ...
\editend
\\
\edithead {\csdag 1 (p23)}
\editstart
\\ \bf new &
\cltxt
Common LISP
characters are partitioned into a unique collection of
repertoires called {\em
Character Registries}. That is, each character is included
in one and only one Character Registry. The label identifying
each character within a Character Registry is a unique numerical value
referred to as the {\em character index}.
\\ &
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers. That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
Character codes are composed from a Character Registry and a
character index. The convention by which a character index and
Character Registry compose a character code is implementation
dependent.
\editend
\subsubsection{String Characters} % 2.2.5.
\edithead {\csdag delete entire section (p23)}
\editstart
\editend
\setcounter{subsection}{4}
\subsubsection{Character Registries} % 2.2.5.
\edithead {\csdag new section (p23)}
\editstart
\\ \bf new &
\cltxt
Character registries provide portable specifications of
character objects. Every character object is uniquely
identified by a registry name and index.
Character Registry names are strings formed from the Common LISP
{\clkwd standard-p} characters. Within registry names, alphabetic
case is ignored.
\\ &
Common LISP defines the following Character Registries:
\footnote{This document
defines a partial list of
the Character Registry names. A subsequent
document will define the complete Common LISP Character Registry
Standard including the effect of the character predicates
{\em alpha-char-p},
{\em lower-case-p}, etc..}
\begin{itemize}
\item Arabic
\item Armenian
\item Bo-po-mo-fo
\item Control
\item Cyrillic
\item Georgian
\item Greek
\item Hangul
\item Hebrew
\item Hiragana
\item Japanese-Punctuation
\item Kanji-JIS-Level-1
\item Kanji-JIS-Level-2
\item Kanji-Gaiji
\item Katakana
\item Latin
\item Latin-Punctuation
\item Mathematical
\item Pattern
\item Phonetic
\item Technical
\end{itemize}
\editend
\\
\edithead {\csdag new section (p23)}
\editstart
\\ \bf new &
\cltxt
The Common LISP Character Registry Standard is fixed;
an implementation
may not extend the set of characters within any Common LISP
Character Registry.
\\ &
An implementation may provide support for all or part of any Common LISP
Character Registry
and may provide new character registries which include characters
having unique semantics (i.e. not defined in any other
implementation-defined character registry or Common LISP Character
Registry). Implementation registries must be uniquely
named using only {\clkwd standard-p} characters. In addition,
the repertoire names {\em base} and {\em standard} have
reserved Common LISP usage.
\\ &
An implementation must document the registries it supports.
For each registry supported,
an implementation must define individual characters supported
including at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions.
\item $<$ Common LISP
Character Registry name, character index $>$ pair if one exists
otherwise $<$ implementation-defined
character registry name, character index $>$ pair.
\item Reader Canonicalization.
\item Position in total ordering.
The partial ordering of the Standard alphanumeric
characters must be preserved.
\item Effect of character predicates.
In particular,
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd standard-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O. In particular, the
coded character set standards
\footnote{For example, "ISO8859/1-1987ccs".} and
external encoding schemes
\footnote{For example, {\em "Xerox System Integration Character
Code Standard"}\cite{xerox87}.}
which are supported must be specified.
\end{itemize}
\editend
\subsection{Symbols} % 2.3.
\edithead {\csdag 12 (p25)}
\editstart
\\ \bf replace &
\cltxt
A symbol may have uppercase letters, lowercase letters, or both
in its print name.
\\ \bf with &
\cltxt
A symbol may have characters from any supported character registry
in its print name.
It may have uppercase letters, lowercase letters, or both.
\editend
\setcounter{subsection}{4}
\subsection{Arrays}
\subsubsection{Vectors}
\edithead {\csdag 6 (p29)}
\editstart
\\ \bf replace &
\cltxt
All implementations provide specialized arrays for the cases when
the components are characters (or rather, a special subset of the
characters);
\\ \bf with &
\cltxt
All implementations provide specialized arrays for the cases when
the components are characters (or optionally, special subsets of
the characters);
\editend
\subsubsection{Strings}
\edithead {\csdag 1 (p30)}
\editstart
\\ \bf replace &
\cltxt
A string is simply a vector of characters. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd string-char}.
\\ \bf with &
\cltxt
A string is simply a vector of characters. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype
of character.
\editend
\setcounter{subsection}{14}
\subsection{Overlap, Inclusion, and Disjointness of Types} % 2.15.
\edithead {\csdag 14 (p34)}
\editstart
\\ \bf replace &
\cltxt
The type {\clkwd standard-char} is a subtype of {\clkwd string-char};
{\clkwd string-char} is a subtype of {\clkwd character}.
\\ \bf with &
\cltxt
The type {\clkwd base-character} is a subtype of
{\clkwd character}.
\editend
\\
\edithead {\csdag 15 (p34)}
\editstart
\\ \bf replace &
\cltxt
The type {\clkwd string} is a subtype of {\clkwd vector},
for {\clkwd string} means {\clkwd (vector string-char)}.
\\ \bf with &
\cltxt
The type {\clkwd string} is a subtype of {\clkwd vector},
{\clkwd string} consists of vectors specialized by subtypes of
{\clkwd character}.
\editend
\\
\edithead {\csdag 15 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd base-string} means
{\clkwd (vector base-character)}.
\editend
\\
\edithead {\csdag 15 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd general-string} means
{\clkwd (vector character)} and is a subtype of {\clkwd string}.
\editend
\\
\edithead {\csdag 20 (p34)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd (simple-array string-char (*))};
\\ \bf with &
\cltxt
{\clkwd (simple-array character (*))};
\editend
\\
\edithead {\csdag 20 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd simple-base-string} means
{\clkwd (simple-array base-character (*))} and
is the most efficient string which can hold
the standard characters. {\clkwd simple-base-string}
is a subtype of {\clkwd base-string}.
\editend
\\
\edithead {\csdag 20 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd simple-general-string} means
{\clkwd (simple-array character (*))}.
{\clkwd simple-general-string}
is a subtype of {\clkwd general-string}.
\editend
%----------------------------------------------------------------------
\setcounter{section}{3}
\section{Type Specifiers} % 4
%----------------------------------------------------------------------
\setcounter{subsection}{1}
\subsection{Type Specifier Lists} % 4.2.
\edithead {\csdag 8 Table 4-1 (alphabetic list) (p43)}
\editstart
\\ \bf remove &
\\ &
\cltxt
{\clkwd standard-char}
\\ &
{\clkwd string-char}
\editend
\\
\edithead {\csdag 8 Table 4-1 (alphabetic list) (p43)}
\editstart
\\ \bf insert &
\\ &
\cltxt
{\clkwd base-character}
\\ &
{\clkwd general-string}
\\ &
{\clkwd simple-base-string}
\\ &
{\clkwd simple-general-string}
\editend
\setcounter{subsection}{2}
\subsection{Predicating Type Specifiers} % 4.3.
\edithead {\csdag 2 (p43)}
\editstart
\\ \bf delete &
\cltxt
As an example, the entire ...
\editend
\\
\edithead {\csdag 3 delete example (p43)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (deftype string-char () } ...
\editend
\setcounter{subsection}{4}
\subsection{Type Specifiers That Specialize} % 4.5.
\edithead {\csdag 5 after (p46)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd (character {\em registries})}
\\ &
This denotes a character type specialized to members
of the specified registries. {\em registries} may be a
single character registry name or a list of
character registry names.
\editend
\setcounter{subsection}{5}
\subsection{Type Specifiers That Abbreviate} % 4.6.
\edithead {\csdag 20 (p49)}
\editstart
\\ \bf replace &
\cltxt
Means the same as {\clkwd (array string-char ({\em size}))}: the set of
strings of
the indicated size.
\\ \bf with &
\cltxt
Means the union of the vector types specialized by subtypes of
character
and the indicated size.
For the purpose of declaration, it is equivalent to
{\clkwd (general-string ({\em size}))}.
\editend
\\
\edithead {\csdag 23 (p49)}
\editstart
\\ \bf replace &
\cltxt
Means the same as {\clkwd (simple-array string-char ({\em size}))}: the
set of simple strings of the indicated size.
\\ \bf with &
\cltxt
Means the union of the simple vector types specialized by subtypes of
character and the indicated size.
For the purpose of declaration, it is equivalent to
{\clkwd (simple-general-string ({\em size}))}.
\editend
\\
\edithead {\csdag 23 after (p49)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd (base-string {\em size})}
\\ &
Means the same as {\clkwd (array base-character ({\em size}))}: the
set of base strings of the indicated size.
\\ &
{\clkwd (simple-base-string {\em size})}
\\ &
Means the same as {\clkwd (simple-array base-character ({\em size}))}:
the set of simple base strings of the indicated size.
\editend
\\
\edithead {\csdag 23 after (p49)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd (general-string {\em size})}
\\ &
Means the same as {\clkwd (array base-character ({\em size}))}: the
set of base strings of the indicated size.
\\ &
{\clkwd (simple-general-string {\em size})}
\\ &
Means the same as
{\clkwd (simple-array general-character ({\em size}))}:
the set of simple general strings of the indicated size.
\editend
\setcounter{subsection}{7}
\subsection{Type Conversion Function} % 4.8.
\edithead {\csdag 6 (p51)}
\editstart
\\ \bf replace &
\cltxt
Some strings, symbols, and integers may be converted to
characters. If {\em object} is a string of length 1,
then the sole element of the print name is returned.
If {\em object} is an integer {\em n}, then {\clkwd (int-char }
{\em n}{\clkwd )} is returned. See {\clkwd character}.
\\ \bf with &
\cltxt
Some strings amd symbols may be converted to
characters. If {\em object} is a string of length 1,
then the sole element of the print name is returned.
See {\clkwd character}.
\editend
\\
\edithead {\csdag 6 after (p52)}
\editstart
\\ \bf insert &
\begin{itemize}
\cltxt
\item Any string subtype may be converted to any other string
subtype, provided the new string can contain all actual
elements of the old string. It is an error if it cannot.
\end{itemize}
\editend
%----------------------------------------------------------------------
\setcounter{section}{5}
\section{Predicates} % 6
%----------------------------------------------------------------------
\edithead {\csdag 2 (p71)}
\editstart
\\ \bf replace &
\cltxt
but {\clkwd standard-char} begets {\clkwd standard-char-p}
\\ \bf with &
\cltxt
but {\clkwd bit-vector} begets {\clkwd bit-vector-p}
\editend
\setcounter{subsection}{1}
\subsection{Data Type Predicates} % 6.2.
\setcounter{subsubsection}{1}
\subsubsection{Specific Data Type Predicates} % 6.2.2.
\edithead {\csdag 36 (p75)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd characterp} {\em object}
\\ \bf with &
\cltxt
{\clkwd characterp} {\em object} \&{\clkwd optional}
{\em repertoire}
\editend
\\
\edithead {\csdag 37 (p75)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd characterp} is true if its argument is a character,
and otherwise is false.
\\ \bf with &
\cltxt
If {\em repertoire} is omitted, {\clkwd characterp}
is true if its argument is a character object,
and otherwise is false.
If a {\em repertoire} argument is specified,
{\clkwd characterp} is true if its argument
is a character object and a member of the specified repertoire,
and
otherwise is false.
For example, {\clkwd (characterp \#$\backslash$A}
{\clkwd "Latin")}
is true since \#$\backslash$A is a member of the Common LISP
Latin Character Registry. {\em repertoire} may be any supported
character registry name or the reserved repertoire names
"base" and "standard". {\clkwd (characterp x "base")} is
true if its argument is a member of the base character
repertoire and false
otherwise.
{\clkwd (characterp x "standard")} is
true if its argument is a member of the standard character
repertoire and false
otherwise.
\editend
\\
\edithead {\csdag 38 (p75)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd (characterp x) $\equiv$ (typep x \apostrophe character)}
\\ \bf with &
\cltxt
{\clkwd (characterp x "standard") $\equiv$ (typep x \apostrophe
(character "standard")}
\editend
\\
\edithead {\csdag 72 (p76)}
\editstart
\\ \bf replace &
\cltxt
See also {\clkwd standard-char-p, string-char-p, streamp,}
\\ \bf with &
\cltxt
See also {\clkwd standard-char-p, streamp,}
\editend
\setcounter{subsubsection}{2}
\subsubsection{Equality Predicates} % 6.2.3.
\edithead {\csdag 75 (p81)}
\editstart
\\ \bf replace &
\cltxt
which ignores alphabetic case and certain other attributes
of characters;
\\ \bf with &
\cltxt
which ignores alphabetic case
of characters;
\editend
%----------------------------------------------------------------------
\setcounter{section}{6}
\section{Control Structure} % 7
%----------------------------------------------------------------------
\setcounter{subsection}{1}
\subsection{Generalized Variables} % 7.2.
\edithead {\csdag 19 modify table (p95)}
\editstart
\\ \bf replace &
\cltxt
char string-char
\\ &
schar string-char
\\ \bf with &
\cltxt
char character
\\ &
schar character
\\ &
sbchar base-character
\editend
\\
\edithead {\csdag 22 table entry (p96)}
\editstart
\\ \bf delete &
\cltxt
char-bit first set-char-bit
\editend
%----------------------------------------------------------------------
∂12-Jan-89 2343 Common-Lisp-mailer cs proposal part 3 of 3
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 23:41:27 PST
Date: Thu, 12 Jan 89 22:17:09 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890112.221709.baggins@almvma>
Subject: cs proposal part 3 of 3
%----------------------------------------------------------------------
\setcounter{section}{9}
\section{Symbols} % 10
%----------------------------------------------------------------------
\edithead {\csdag 3 (p163)}
\editstart
\\ \bf replace &
\cltxt
It is ordinarily not permitted to alter a symbol's print name.
\\ \bf with &
\cltxt
It is an error to alter a symbol's print name.
\editend
\setcounter{subsection}{1}
\subsection{The Print Name} % 10.2.
\edithead {\csdag 5 (p168)}
\editstart
\\ \bf replace &
\cltxt
It is an extremely bad idea
\\ \bf with &
\cltxt
It is an error and an extremely bad idea
\editend
%----------------------------------------------------------------------
\setcounter{section}{10}
\section{Packages} % 11
%----------------------------------------------------------------------
\setcounter{subsection}{6}
\subsection{Package System Functions and Variables} % 11.7.
\edithead {\csdag 31 (p184,intern)}
\editstart
\\ \bf append &
\cltxt
All strings, base and extended, are acceptable {\em string}
arguments.
\editend
%----------------------------------------------------------------------
\setcounter{section}{12}
\section{Characters} % 13
%----------------------------------------------------------------------
\edithead {\csdag 6 after (p233)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd char-code-limit} [{\clkwd Constant}]
\\ &
The value of {\clkwd char-code-limit} is a non-negative integer
that is the upper exclusive bound on values produced by the
function {\clkwd char-code}, which returns the {\em code}
of a given character; that is, the values returned by
{\clkwd char-code} are non-negative and strictly less than
the value of {\clkwd char-code-limit}.
There may be unassigned codes between 0 and
{\clkwd char-code-limit} which
are not legal arguments to {\clkwd code-char}.
\\ &
\cltxt
{\clkwd char-index-limit {\em registry}} [{\clkwd Function}]
\\ &
This function returns a non-negative integer
that is the upper exclusive bound on values produced by the
function {\clkwd char-index} for the specified {\em registry}.
There may be unsupported index values between 0 and
{\clkwd char-index-limit}, i.e.
{\clkwd (find-char {\em registry index})} may return {\clkwd nil}.
\\ &
\cltxt
{\clkwd *all-registry-names*} [{\clkwd Constant}]
\\ &
The value of {\clkwd *all-registry-names*} is a list of
all character registry names supported by the implementation.
Only Common LISP Character Registry names or implementation
defined character registries may be included in this list.
In particular, "base" and "standard" are not character registry
names and must not be included.
\editend
\setcounter{subsection}{0}
\subsection{Character Attributes} % 13.1.
\edithead {\csdag delete entire section (p233)}
\editstart
\editend
\setcounter{subsection}{1}
\subsection{Predicates on Characters} % 13.2.
\edithead {\csdag 3 (p234)}
\editstart
\\ \bf replace &
\cltxt
argument is a "standard character" that is, an object of type
{\clkwd standard-char}.
Note that any character with a non-zero {\em bits} or {\em font}
attribute
is non-standard.
\\ \bf with &
\cltxt
argument is one of the Common LISP standard character subrepertoire.
\editend
\\
\edithead {\csdag 4 (p234)}
\editstart
\\ \bf delete &
\cltxt
Note that any character with non-zero ...
\editend
\\
\edithead {\csdag 6 (p235)}
\editstart
\\ \bf replace &
\cltxt
Of the standard characters all but \#$\backslash${\clkwd Newline}
are graphic.
The semi-standard characters \#$\backslash${\clkwd Backspace},
\#$\backslash${\clkwd Tab},
\#$\backslash${\clkwd Rubout},
\#$\backslash${\clkwd Linefeed},
\#$\backslash${\clkwd Return},
and \#$\backslash${\clkwd Page} are not graphic.
\\ \bf with &
\cltxt
Of the standard characters all but \#$\backslash${\clkwd Newline}
are graphic.
\editend
\\
\edithead {\csdag 7 (p235)}
\editstart
\\ \bf delete &
\cltxt
Programs may assume that graphic ...
\editend
\\
\edithead {\csdag 8 (p235)}
\editstart
\\ \bf delete &
\cltxt
Any character with a non-zero bits...
\editend
\\
\edithead {\csdag 9 (p235)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd string-char-p} ...
\editend
\\
\edithead {\csdag 10 (p235)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 13 (p235)}
\editstart
\\ \bf replace &
\cltxt
If a character is alphabetic, then it is perforce graphic. Therefore
any character
with a non-zero bits attribute cannot be alphabetic. Whether a
character is
alphabetic is may depend on its font number.
\\ \bf with &
\cltxt
If a character is alphabetic, then it is perforce graphic.
\editend
\\
\edithead {\csdag 22 (p236)}
\editstart
\\ \bf replace &
\cltxt
If a character is either uppercase or lowercase, it is necessarily
alphabetic (and
therefore is graphic, and therefore has a zero bits attribute).
However, it is permissible in theory for an alphabetic character
to be neither
uppercase nor lowercase (in a non-Roman font, for example).
\\ \bf with &
\cltxt
If a character is either uppercase or lowercase, it is necessarily
alphabetic (and
therefore is graphic).
\editend
\\
\edithead {\csdag 25 (p236)}
\editstart
\\ \bf replace &
\cltxt
The argument {\em char} must be a character object, and {\em radix}
must be a non-negative
integer. If {\em char} is not a digit of the radix specified
\\ \bf with &
\cltxt
The argument {\em char} must be in the standard character
subrepertoire and
{\em radix} must be a non-negative integer.
If {\em char} is not a standard character or is not a digit of the
radix specified
\editend
\\
\edithead {\csdag 51 (p237)}
\editstart
\\ \bf delete &
\cltxt
If two characters have the same bits ...
\editend
\\
\edithead {\csdag 52 (p237)}
\editstart
\\ \bf replace &
\cltxt
If two characters differ in any attribute (code, bits, or font), then
they are different.
\\ \bf with &
\cltxt
If the codes of two characters differ, then
they are different.
\editend
\\
\edithead {\csdag 94 (p239)}
\editstart
\\ \bf replace &
\cltxt
The predicate {\clkwd char-equal} is like {\clkwd char=}, and
similarly for the others, except
according to a different ordering such that differences of bits
attributes and case are ignored, and font information is taken into
account in an implementation dependent manner.
\\ \bf with &
\cltxt
The predicate {\clkwd char-equal} is like {\clkwd char=}, and
similarly for the others, except
according to a different ordering such that differences of case
are ignored.
\editend
\\
\edithead {\csdag 97 example (p239)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char-equal \#$\backslash$A \#$\backslash$Control-A) is true}
\editend
\\
\edithead {\csdag 98 (p239)}
\editstart
\\ \bf delete &
\cltxt
The ordering may depend on the font ...
\editend
\setcounter{subsection}{2}
\subsection{Character Construction and Selection} % 13.3.
\edithead {\csdag 3 (p239)}
\editstart
\\ \bf replace &
\cltxt
The argument {\em char} must be a character object.
{\clkwd char-code} returns the {\em code} attribute of the
character object;
this will be a non-negative integer less than the (normal) value
\\ \bf with &
\cltxt
The argument {\em char} must be a character object.
{\clkwd char-code} returns the {\em code} of the
character object;
this will be a non-negative integer less than the value
\editend
\\
\edithead {\csdag 4 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-bits } ...
\editend
\\
\edithead {\csdag 5 (p240)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 6 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-font } ...
\editend
\\
\edithead {\csdag 7 (p240)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 8 (p240)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd code-char {\em code} \&optional {\em (bits 0) (font 0)}
[{\em Function}]}
\\ \bf with &
\cltxt
{\clkwd code-char {\em code}
[{\em Function}]}
\editend
\\
\edithead {\csdag 9 (p240)}
\editstart
\\ \bf replace &
\cltxt
All three arguments must be non-negative integers. If it is possible
in the
implementation to construct a character object whose code attribute
is {\em code},
whose
bits attribute is {\em bits}, and whose font attribute is {\em font},
then such an object
is returned;
\\ \bf with &
\cltxt
The argument must be a non-negative integer. If it is possible
in the
implementation to construct a character object identified by
{\em code},
then such an object is returned;
\editend
\\
\edithead {\csdag 10 (p240)}
\editstart
\\ \bf replace &
\cltxt
For any integers, {\em c, b,} and {\em f}, if {\clkwd (code-char
{\em c b f})} is
\\ \bf with &
\cltxt
For any integer, {\em c}, if {\clkwd (code-char
{\em c})} is
\editend
\\
\edithead {\csdag 12 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char-bits (code-char } ...
\editend
\\
\edithead {\csdag 13 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char-font (code-char } ...
\editend
\\
\edithead {\csdag 14 (p240)}
\editstart
\\ \bf delete &
\cltxt
If the font and bits attributes ...
\editend
\\
\edithead {\csdag 15 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char= (code-char (char-code ...}
\editend
\\
\edithead {\csdag 16 (p240)}
\editstart
\\ \bf delete &
\cltxt
is true.
\editend
\\
\edithead {\csdag 17 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd make-char} ...
\editend
\\
\edithead {\csdag 18 (p240)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 19 (p240)}
\editstart
\\ \bf delete &
\cltxt
If {\em bits} or {\em font} are zero ...
\editend
\\
\edithead {\csdag 19 (p240)}
\editstart
\\ \bf append &
\cltxt
{\clkwd find-char} {\em index registry} [{\em Function}]
\\ &
{\clkwd find-char} returns a character object.
{\em index} is an integer
value uniquely identifying a character within the character
registry name {\em registry}.
If the implementation does not support the specified
character, {\clkwd nil} is returned.
\editend
\setcounter{subsection}{3}
\subsection{Character Conversions} % 13.4.
\edithead {\csdag 8 (p241)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd char-upcase} returns a character object with the same
font and bits attributes as {\em char}, but with possibly a
different code attribute.
\\ \bf with &
\cltxt
{\clkwd char-upcase} returns a character object with possibly
a different code.
\editend
\\
\edithead {\csdag 10 (p241)}
\editstart
\\ \bf replace &
\cltxt
Similarly, {\clkwd char-downcase} returns a character object with the
same font and bits attributes as {\em char}, but with possibly a
different code attribute.
\\ \bf with &
\cltxt
Similarly, {\clkwd char-downcase} returns a character object with
possibly a different code.
\editend
\\
\edithead {\csdag 12 (p241)}
\editstart
\\ \bf delete &
\cltxt
Note that the action of ...
\editend
\\
\edithead {\csdag 13 (p241)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd digit-char {\em weight} \&optional ({\em radix} 10)
({\em font} 0) [{\em Function}]}
\\ \bf with &
\cltxt
{\clkwd digit-char {\em weight} \&optional ({\em radix} 10)
[{\em Function}]}
\editend
\\
\edithead {\csdag 14 (p241)}
\editstart
\\ \bf replace &
\cltxt
All arguments must be integers. {\clkwd digit-char} determines
whether or not it is
possible
to construct a character object whose font attribute is {\em font},
and whose {\em code}
\\ \bf with &
\cltxt
All arguments must be integers. {\clkwd digit-char} determines
whether or not it is
possible to construct a character object whose {\em code}
\editend
\\
\edithead {\csdag 15 (p242)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd digit-char} cannot return {\clkwd nil} if {\em font}
is zero, {\em radix}
\\ \bf with &
\cltxt
{\clkwd digit-char} cannot return {\clkwd nil}.
{\em radix}
\editend
\\
\edithead {\csdag 22 (p242)}
\editstart
\\ \bf delete &
\cltxt
Note that no argument is provided for ...
\editend
\\
\edithead {\csdag 23 through 30 (p242, char-int, int-char)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-int} {\em char}
\editend
\\
\edithead {\csdag 32 (p242)}
\editstart
\\ \bf replace &
\cltxt
All characters that have zero font and bits attributes and that are
non-graphic
\\ \bf with &
\cltxt
All characters that are
non-graphic
\editend
\\
\edithead {\csdag 33 (p243)}
\editstart
\\ \bf replace &
\cltxt
The standard newline and space characters have the respective
names {\clkwd Newline} and {\clkwd Space}. The semi-standard
characters have the names {\clkwd Tab, Page, Rubout, Linefeed,
Return,} and {\clkwd Backspace}.
\\ \bf with &
\cltxt
The standard newline and space characters have the respective
names {\clkwd Newline} and {\clkwd Space}.
\editend
\\
\edithead {\csdag 35 (p243)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-name} will only locate "simple" ...
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd name-char} may accept other names for characters
in addition to those returned by {\clkwd char-name}.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd char-registry} {\em char} [{\em Function}]
\\ &
{\clkwd char-registry} returns a string value representing
the character registry to which {\em char} belongs.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd char-index} {\em char} [{\em Function}]
\\ &
{\clkwd char-index} returns an integer value representing
the character (registry) index of {\em char}.
\editend
\setcounter{subsection}{4}
\subsection{Character Control-Bit Functions} % 13.5.
\edithead {\csdag delete entire section (p243)}
\editstart
\editend
%----------------------------------------------------------------------
\setcounter{section}{13}
\section{Sequences} % 14
%----------------------------------------------------------------------
\setcounter{subsection}{0}
\subsection{Simple Sequence Functions} % 14.1
\edithead {\csdag 21 (p249,make-sequence)}
\editstart
\\ \bf append &
\cltxt
If type {\clkwd string} is specified, the result is
equivalent to {\clkwd make-string}.
\editend
%----------------------------------------------------------------------
\setcounter{section}{17}
\section{Strings} % 18
%----------------------------------------------------------------------
\edithead {\csdag 1 (p299)}
\editstart
\\ \bf replace &
\cltxt
Specifically, the type {\clkwd string} is identical to the type
{\clkwd (vector string-char),}
which in turn is the same as {\clkwd (array string-char (*))}.
\\ \bf with &
\cltxt
Specifically, the type {\clkwd string} is a subtype of
{\clkwd vector}
and consists of vectors specialized by subtypes of {\clkwd character}.
\editend
\setcounter{subsection}{0}
\subsection{String Access} % 18.1.
\edithead {\csdag 3 (p300)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd sbchar} {\em simple-base-string index} [{\em Function}]
\editend
\\
\edithead {\csdag 4 (p300)}
\editstart
\\ \bf replace &
\cltxt
character object. (This character will necessarily satisfy the
predicate
{\clkwd string-char-p}).
\\ \bf with &
\cltxt
character object.
\editend
\\
\edithead {\csdag 9 (p300)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd setf} may be used with {\clkwd char} to destructively
replace a character within a string.
\\ \bf with &
\cltxt
{\clkwd setf} may be used with {\clkwd char} to destructively
replace a character within a string.
The new character must be of a type which can be stored in the
string; it is an error otherwise.
\editend
\\
\edithead {\csdag 10 (p300)}
\editstart
\\ \bf insert &
\cltxt
For {\clkwd sbchar}, the string must be a simple base string.
The new character must be of a type which can be stored in the
string; it is an error otherwise.
\editend
\setcounter{subsection}{2}
\subsection{String Construction and Manipulation} % 18.3.
\edithead {\csdag 2 (p302)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd make-string {\em size} \&key :initial-element [{\em Function}]}
\\ \bf with &
\cltxt
{\clkwd make-string {\em size} \&key :initial-element :element-type
[{\em Function}]}
\editend
\\
\edithead {\csdag 3 (p302,make-string)}
\editstart
\\ \bf replace &
\cltxt
This returns a string (in fact a simple string) of length {\em size},
each of whose characters has been initialized to the
{\clkwd :initial-element} argument. If an {\clkwd :initial-element}
argument is not specified, then the string will be initialized
in an implementation-dependent way.
\\ \bf with &
\cltxt
This returns a string of length {\em size},
each of whose characters has been initialized to the
{\clkwd :initial-element} argument. If an {\clkwd :initial-element}
argument is not specified, then the string will be initialized
in an implementation-dependent way.
The {\clkwd :element-type} argument names the type of the elements
of the string; a string is constructed of the most specialized
type that can accommodate elements of the given type.
If {\clkwd :element-type} is omitted, the type
{\clkwd simple-string} is the default.
\editend
\\
\edithead {\csdag 5 (p302,make-string)}
\editstart
\\ \bf replace &
\cltxt
A string is really just a one-dimensional array of "string
characters" (that is,
those characters that are members of type {\clkwd string-char}).
More complex character arrays may be constructed using the function
{\clkwd make-array}.
\\ \bf with &
\cltxt
More complex character arrays may be constructed using the function
{\clkwd make-array}.
\editend
\\
\edithead {\csdag 29 (p304,make-string)}
\editstart
\\ \bf replace &
\cltxt
If {\em x} is a string character (a character of type
{\clkwd string-char}), then
\\ \bf with &
\cltxt
If {\em x} is a character, then
\editend
%----------------------------------------------------------------------
\setcounter{section}{21}
\section{Input/Output} % 22
\setcounter{subsection}{0}
\subsection{Printed Representation of LISP Objects} % 22.1.
\setcounter{subsubsection}{0}
\subsubsection{What the Read Function Accepts} % 22.1.1.
\edithead {\csdag Table 22-1: Standard Character Syntax Types (p336)}
\editstart
\\ \bf delete entry &
\cltxt
{\clkwd <tab>} {\em whitespace}
\\ &
{\clkwd <page>} {\em whitespace}
\\ &
{\clkwd <backspace>} {\em constituent}
\\ &
{\clkwd <return>} {\em whitespace}
\\ &
{\clkwd <rubout>} {\em constituent}
\\ &
{\clkwd <linefeed>} {\em whitespace}
\editend
\setcounter{subsubsection}{1}
\subsubsection{Parsing of Numbers and Symbols} % 22.1.2.
\edithead {\csdag Table 22-3: Standard Constituent Character
Attributes (p340)}
\editstart
\\ \bf delete entry &
\cltxt
{\clkwd <backspace>} {\em illegal}
\\ &
{\clkwd <tab>} {\em illegal}
\\ &
{\clkwd <linefeed>} {\em illegal}
\\ &
{\clkwd <page>} {\em illegal}
\\ &
{\clkwd <return>} {\em illegal}
\\ &
{\clkwd <rubout>} {\em illegal}
\editend
\setcounter{subsubsection}{3}
\subsubsection{Standard Dispatching Macro Character Syntax} % 22.1.4.
\edithead {\csdag Table 22-4: Standard \# Macro Character Syntax (p352)}
\editstart
\\ \bf delete entry &
\cltxt
{\clkwd \#<backspace>} {\em signals error}
\\ &
{\clkwd \#<tab>} {\em signals error}
\\ &
{\clkwd \#<linefeed>} {\em signals error}
\\ &
{\clkwd \#<page>} {\em signals error}
\\ &
{\clkwd \#<return>} {\em signals error}
\\ &
{\clkwd \#<rubout>} {\em undefined}
\editend
\\
\edithead {\csdag 8 (p353)}
\editstart
\\ \bf replace &
\cltxt
The following names are standard across all implementations:
\\ \bf with &
\cltxt
All non-graphic
characters, including extended characters, are uniquely
named in an implementation-dependent manner.
The following names are standard across all implementations:
\editend
\\
\edithead {\csdag 11 through 18 inclusive delete (p353)}
\editstart
\\ \bf delete &
\cltxt
The following names are semi-standard; ...
\editend
\\
\edithead {\csdag 20 through 26 inclusive delete (p354)}
\editstart
\\ \bf delete &
\cltxt
The following convention is used in implementations ...
\editend
\\
\edithead {\csdag 108 (p360)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd \#<space>, \#<tab>, \#<newline>, \#<page>, \#<return>}
\\ \bf with &
\cltxt
{\clkwd \#<space>, \#<newline>}
\editend
\setcounter{subsubsection}{4}
\subsubsection{The Readtable} % 22.1.5.
\edithead {\csdag 3 (p360)}
\editstart
\\ \bf replace &
\cltxt
Even if an implementation supports characters with non-zero
{\em bits} and {\em font}
attributes, it need not (but may) allow for such characters to
have syntax
descriptions
in the readtable. However, every character of type
{\clkwd string-char}
must be represented in the readtable.
\\ \bf with &
\cltxt
All base and extended characters
are representable in the readtable.
\editend
\setcounter{subsubsection}{5}
\subsubsection{What the Print Function Produces} % 22.1.6.
\edithead {\csdag 13 (p366)}
\editstart
\\ \bf replace &
\cltxt
is used. For example, the printed representation of the character
\#$\backslash$A
with control
and meta bits on would be \#$\backslash${\clkwd CONTROL-META-A},
and that of
\#$\backslash$a with control and meta bits on would be
\#$\backslash${\clkwd CONTROL-META-$\backslash$a}.
\\ \bf with &
\cltxt
is used (see 22.1.4).
\editend
\setcounter{subsection}{2}
\subsection{Output Functions} % 22.3.
\setcounter{subsubsection}{0}
\subsubsection{Output to Character Streams} % 22.3.1.
\edithead {\csdag 26 (p384)}
\editstart
\\ \bf replace &
\cltxt
({\em not} the substring delimited by {\clkwd :start} and
{\clkwd :end}).
\\ \bf with &
({\em not} the substring delimited by {\clkwd :start} and
{\clkwd :end}).
Only characters which are members of the coded character set(s)
associated with the output stream or \#$\backslash${\clkwd Newline}
are valid to be written;
it is an error otherwise. All character streams must provide
appropriate line division behavior for
\#$\backslash${\clkwd Newline}.
\editend
\\
\edithead {\csdag 27 after (p384)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd external-width} {\em object} \&{\clkwd optional}
{\em output-stream} [{\em Function}]
\\ &
{\clkwd external-width} returns the number of host system base
character units required for the object on the output-stream. If
not applicable to the output stream, the function
returns {\clkwd nil}.
This number corresponds to the current state of the stream
and may change if there has been intervening output.
If the output stream is not specified {\clkwd *standard-output*}
is the default.
\editend
\footnote{
The X3 J13 proposal STREAM-INFO: ONE-DIMENSIONAL-FUNCTIONS
modified to include these semantics is an
acceptable alternative to the {\clkwd external-width} function
proposed here.}
\setcounter{subsubsection}{2}
\subsubsection{Formatted Output to Character Streams} % 22.3.3.
\edithead {\csdag 23 delete example (p387)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (format nil "Type} $\tilde{ }$
{\clkwd :C to $\tilde{ }$ :A."} . . .
\editend
\\
\edithead {\csdag 66 (p389)}
\editstart
\\ \bf replace &
\cltxt
$\tilde{ }${\clkwd :C} spells out the names of the control bits and
represents non-printing
characters by their names: {\clkwd Control-Meta-F, Control-Return,
Space}.
This is a "pretty" format for printing characters.
\\ \bf with &
\cltxt
$\tilde{ }${\clkwd :C}
represents non-printing
characters by their names: {\clkwd Newline,
Space}. This is a "pretty" format
for printing characters.
\editend
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\setcounter{section}{22}
\section{File System Interface} % 23
\setcounter{subsection}{1}
\subsection{Opening and Closing Files} % 23.2.
\edithead {\csdag 2 (p418)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd open {\em filename} \&key :direction :element-type}
{\clkwd :if-exists :if-does-not-exist}
[{\em Function}]
\\ \bf with &
\cltxt
{\clkwd open {\em filename} \&key :direction :element-type}
{\clkwd
:external-code-format}
{\clkwd :if-exists :if-does-not-exist}
[{\em Function}]
\editend
\\
\edithead {\csdag 11 (p419)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd string-char}
\\ &
The unit of transaction is a string-character. The functions
{\clkwd read-char}
and/or {\clkwd write-char} may be used on the stream.
\\ \bf with &
\cltxt
The default value of {\clkwd :element-type} is an
implementation-defined subtype of character.
\\ &
{\clkwd base-character}
\\ &
The unit of transaction is a base character. The functions
{\clkwd read-char}
and/or {\clkwd write-char} may be used on the stream. This is
the default.
\editend
\\
\edithead {\csdag 16 (p419)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd character}
\\ &
The unit of transaction is any character, not just a string-character.
The functions {\clkwd read-char} and/or {\clkwd write-char} may
be used on the stream.
\\ \bf with &
\cltxt
{\clkwd character}
\\ &
The unit of transaction is any character.
The functions {\clkwd read-char} and/or {\clkwd write-char} may
be used on the stream.
\editend
\\
\edithead {\csdag 19 after (p420)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd :external-code-format}
\\ &
This argument specifies a string or list of
string(s) indicating an implementation recognized scheme for
representing 1 or more coded character sets with non-homogeneous codes.
\\ &
The default value is "default" and is
implementation defined but must include the
base characters.
\\ &
As many coded character set names must be provided as the
implementation requires for that external coding convention.
\\ &
References to standard ISO coded character set names must
include the full ISO reference number and approval year followed
by "ccs". The following are valid ISO reference names:
"ISO8859/1-1987ccs", "ISO6937/2-1983ccs", "iso646-1983ccs", etc..
All implementation recognized schemes are formed from
{\clkwd standard-p} characters. Within scheme names,
alphabetic case is ignored.
\editend
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Deprecated Language Features}
The X3 J13 Character subcommittee proposal
will cause certain areas of \cite{steele84} to
become obsolete. We have included in this appendix, potential
additions to the standard document for areas we feel are important
in the interest of compatibility. The character subcommittee
recommends that the X3 J13 committee as a whole adopt a
policy regarding obsolescence. This policy
may be to keep the obsolete function in the interest of
compatibility for existing applications, or
to drop the obsolete function completely. One compromise
is to document these functions in an appendix to the Common LISP
Standard. The appendix would be for informational use only
and not a part of the standard definition.
%----------------------------------------------------------------------
\setcounter{section}{1}
\section{Data Types} % 2
%----------------------------------------------------------------------
\setcounter{subsection}{14}
\subsection{Overlap, Inclusion, and Disjointness of Types} % 2.15.
\edithead {\csdag 14 (p34)}
\editstart
\\ \bf deprecated &
\cltxt
The type {\clkwd standard-char} is a subtype of
{\clkwd base-character};
The type {\clkwd string-char} is implementation defined as either
{\clkwd base-character} or {\clkwd character}.
\editend
%----------------------------------------------------------------------
\setcounter{section}{12}
\section{Characters} % 13
%----------------------------------------------------------------------
\edithead {\csdag throughout}
\editstart
\\ \bf deprecated &
\cltxt
Earlier versions of Common LISP incorporated {\em font} and
{\em bits} as attributes of character objects.
There are several functions which were removed
from the language or modified by this proposal.
The deleted functions and constants include:
\begin{itemize}
\item char-font-limit
\item char-bits-limit
\item int-char
\item char-int
\item char-bits
\item char-font
\item make-char
\item char-control-bit
\item char-meta-bit
\item char-super-bit
\item char-hyper-bit
\item char-bit
\item set-char-bit
\end{itemize}
\editend
\\
\edithead {\csdag (p233)}
\editstart
\\ \bf deprecated &
\cltxt
If supported by an implementation these attributes may
effect the action of selected functions. In particular,
the following effects noted:
\\ &
\begin{itemize}
\item Attributes, such as those
dealing with how the character is displayed or its typography,
are not part of the character code.
For example, bold-face, color
or size are not considered part of the character code.
\item If two characters differ in any attributes,
then they are not {\clkwd char=}.
\item If two characters have identical
attributes, then their ordering by
{\clkwd char}$<$ is consistent with the numerical ordering by the
predicate $<$ on
their code attributes. (Similarly for {\clkwd char}$>$,
{\clkwd char}$>=$ and {\clkwd char}$<=$.)
\item The effect, if any, on {\clkwd char-equal} of each
attribute has to be specified as part of
the definition of that attribute.
\item The effect of {\clkwd char-upcase} and {\clkwd char-downcase}
is to preserve attributes.
\item The function {\clkwd char-int} is equivalent to {\clkwd char-code}
if no attributes are associated with
the character object.
\item The function {\clkwd int-char} is equivalent to {\clkwd code-char}
if no attributes are associated with
the character object.
\item It is implementation dependent whether characters within
double quotes have attributes removed.
\item It is implementation dependent whether
attributes are removed from symbol names by {\clkwd read}.
\item Even if an implementation supports characters with non-zero
{\em bits} and {\em font}
attributes, it need not (but may) allow for such characters to
have syntax descriptions
in the readtable.
\end{itemize}
\editend
%----------------------------------------------------------------------
\begin{thebibliography}{wwwwwwww 99}
\bibitem[Ida87]{ida87} M. Ida, et al.,
{\em
JEIDA Common LISP Committee Proposal on Embedding Multi-Byte Characters
},
ANSI X3J13 document 87-022, (1987).
\bibitem[ISO 646]{iso646} ISO,
{\em
Information processing -- ISO 7-bit coded character set
for information interchange
},
ISO (1983).
\bibitem[ISO 4873]{iso4873} ISO,
{\em
Information processing -- ISO 8-bit code for information
interchange -- Structure and rules for implementation
},
ISO (1986).
\bibitem[ISO 6937/1]{iso6937/1} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 1: General introduction
},
ISO (1983).
\bibitem[ISO 6937/2]{iso6937/2} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 2: Latin alphabetic and non-alphabetic
graphic characters
},
ISO (1983).
\bibitem[ISO 8859/1]{iso8859/1} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. 1
},
ISO (1987).
\bibitem[ISO 8859/2]{iso8859/2} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 2: Latin alphabet No. 2
},
ISO (1987).
\bibitem[ISO 8859/6]{iso8859/6} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 6: Latin/Arabic alphabet
},
ISO (1987).
\bibitem[ISO 8859/7]{iso8859/7} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 7: Latin/Greek alphabet
},
ISO (1987).
\bibitem[Kerns87]{kerns87} R. Kerns,
{\em
Extended Characters in Common LISP
},
X3J13 Character Subcommittee document, Symbolics Inc (1987).
\bibitem[Kurokawa88]{kurokawa88} T. Kurokawa, et al.,
{\em
Technical Issues on International Character Set Handling in Lisp
},
ISO/IEC SC22 WG16 document N33, (1988).
\bibitem[Linden87]{linden87} T. Linden,
{\em
Common LISP - Proposed Extensions for International Character Set
Handling
},
Version 01.11.87, IBM Corporation (1987).
\bibitem[Steele84]{steele84} G. Steele Jr.,
{\em
Common LISP: the Language
},
Digital Press (1984).
\bibitem[Xerox87]{xerox87} Xerox,
{\em
Character Code Standard, Xerox System Integration Standard
},
Xerox Corp. (1987).
\end{thebibliography}
\end{document} % End of document.
∂13-Jan-89 1055 @MCC.COM,@AMMON.ACA.MCC.COM:ai.clive@MCC.COM Test message
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89 10:55:36 PST
Received: from AMMON.ACA.MCC.COM by MCC.COM with TCP/SMTP; Fri 13 Jan 89 12:40:11-CST
Date: Fri, 13 Jan 89 12:59 CST
From: Clive B. Dawson <ai.clive@MCC.COM>
Subject: Test message
Message-ID: <19890113185930.2.CLIVE@AMMON.ACA.MCC.COM>
bcc: CLisp-Dis@MCC.COM
This message is just a test of a future common lisp mail distribution point from
MCC.COM. Please disregard this message.
∂13-Jan-89 1709 Common-Lisp-mailer Re: commonlisp types
Received: from fs3.cs.rpi.edu by SAIL.Stanford.EDU with TCP; 13 Jan 89 17:09:41 PST
Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept)
id AA11907; Fri, 13 Jan 89 20:05:15 EST
Date: Fri, 13 Jan 89 17:30:43 EST
From: harrisr@turing.cs.rpi.edu (Richard Harris)
Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept)
id AA05864; Fri, 13 Jan 89 17:30:43 EST
Message-Id: <8901132230.AA05864@turing.cs.rpi.edu>
To: RWK%FUJI.ILA.Dialnet.Symbolics.Com@riverside.scrc.symbolics.com,
common-lisp@sail.stanford.edu
Subject: Re: commonlisp types
Date: Mon, 9 Jan 89 21:42 EST
From: Robert W. Kerns <RWK@F.ILA.Dialnet.Symbolics.COM>
OK, next question: Does it open-code or otherwise optimize TYPEP, or
just call TYPEP on the list?
KCL just calls TYPEP on the list.
One of the patches that I have made to KCL is a version of TYPEP
that open-codes when the type is a constant, but my patch has the bug.
Richard Harris
∂14-Jan-89 2000 Common-Lisp-mailer Logical Operations on Numbers
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Jan 89 19:59:57 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03650g; Sat, 14 Jan 89 19:55:17 PST
Received: by bhopal id AA10940g; Sat, 14 Jan 89 19:57:36 PST
Date: Sat, 14 Jan 89 19:57:36 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901150357.AA10940@bhopal>
To: ELIOT@cs.umass.EDU
Cc: common-lisp@sail.stanford.EDU
In-Reply-To: ELIOT@cs.umass.EDU's message of Thu, 12 Jan 89 15:31 EST <8901122046.AA00579@crash.cs.umass.edu>
Subject: Logical Operations on Numbers
For what it's worth, Johan DeKleer at Xerox PARC asked for just such
functionality back in 1984. I don't remember what the public response
was then -- I seem to remember everyone trying to write clever, short
code sequences that would "do the trick". But the gaping hole still
stands. If just one more person seems to thinkg it is a good idea,
then that should carry much force with the X3J13 committee.
-- JonL --
∂16-Jan-89 1650 Common-Lisp-mailer Logical Operations on Numbers
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 16 Jan 89 16:50:50 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 260510; Mon 16-Jan-89 19:48:35 EST
Date: Mon, 16 Jan 89 19:48 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Logical Operations on Numbers
To: jonl@lucid.com, ELIOT@cs.umass.EDU
cc: common-lisp@sail.stanford.EDU
In-Reply-To: <8901150357.AA10940@bhopal>
Message-ID: <19890117004819.7.GSB@ANNISQUAM.SCRC.Symbolics.COM>
Date: Sat, 14 Jan 89 19:57:36 PST
From: Jon L White <jonl@lucid.com>
For what it's worth, Johan DeKleer at Xerox PARC asked for just such
functionality back in 1984. I don't remember what the public response
was then -- I seem to remember everyone trying to write clever, short
code sequences that would "do the trick". But the gaping hole still
stands. If just one more person seems to thinkg it is a good idea,
then that should carry much force with the X3J13 committee.
-- JonL --
Logical subsetp is in the critical path of a peephole optimizer i just
wrote. For efficiency reasons, though, the code was reorganized so that
in any given instantiation the size was fixed, and some complicated
macrology ends up turning things into manipulation of lists of fixnums.
(here's an application for the fixnum type which can enhance
portability...)
I could see having this kind of predicate for both integers and
bitvectors, and could imagine a sufficiently powerful compiler handling
it (and other bit and logical operations) efficiently.
∂19-Jan-89 0953 Common-Lisp-mailer Logical Operations on Numbers
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 19 Jan 89 09:52:58 PST
Received: from vax3.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
id AA06071; Thu, 19 Jan 89 12:53:38 est
Message-Id: <8901191753.AA06071@crash.cs.umass.edu>
Date: Thu, 19 Jan 89 12:53 EST
From: ELIOT@cs.umass.EDU
Subject: Logical Operations on Numbers
To: Common-Lisp@sail.stanford.EDU
X-Vms-To: IN%"Common-Lisp@sail.stanford.edu"
Rather than duplicating the subset operations on both numbers and bitvectors
why not make the generic arithmetic routines accept bitvectors as non-negative
integers? The generic arithmetic routines already handle so many types
that one more can't make a big difference. Many numeric routines make
sense and extend the functionality if they could be applied to bitvector
For example, ZEROP (null set), =, /=, logXXX, boole,lognot, logtest,
logcount, integer-length.
However, bitvectors have never been very useful to me because of the
restriction that the bit-XXX operations can only work on arrays
of the same DIMENSIONS. If this were relaxed and the smaller array was
treated as being extended with zeros I think they would be much more useful.
Chris Eliot
∂20-Jan-89 0834 Common-Lisp-mailer LOGICAL OPERATIONS ON NUMBERS
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 20 Jan 89 08:34:43 PST
Received: from relay2.cs.net by RELAY.CS.NET id aj08866; 20 Jan 89 8:51 EST
Received: from draper.com by RELAY.CS.NET id aa25245; 20 Jan 89 8:46 EST
Return-path: seb1525@mvs.draper.com
Received: from MVS.DRAPER.COM by DRAPER.COM via TCP; Fri Jan 20 08:16 EST
Received: by MVS.DRAPER.COM with NETMAIL; FRI, 20 JAN 89 08:16 EST
Date: FRI, 20 JAN 89 08:13 EST
From: SEB1525@mvs.draper.com
Subject: LOGICAL OPERATIONS ON NUMBERS
To: common-lisp@SAIL.STANFORD.EDU
Reply-to: seb1525@draper.com
X-MVS-to: common-lisp@sail.stanford.edu
Message-Id: <NETMAILR09012008133SEB1525@MVS.DRAPER.COM>
Isn't SUBSETP of A and B, where A and B are integers, implementable by
(eql B (logior A B))
?
∂20-Jan-89 1234 Common-Lisp-mailer New Mail Address
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Jan 89 12:34:07 PST
Received: from decvax.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for common-lisp@sail.stanford.edu; id AA14762; Fri, 20 Jan 89 12:31:42 PST
Received: from thor.prime.com by cvbnet.prime.com (3.2/SMI-3.2)
id AA04473; Fri, 20 Jan 89 15:28:47 EST
Received: from giants.uucp by thor.prime.com (3.2/3.14)
id AA08730; Fri, 20 Jan 89 15:22:47 EST
Return-Path: <tbardasz@giants>
Received: by giants.uucp (3.2/SMI-3.0DEV3)
id AA04231; Fri, 20 Jan 89 15:23:00 EST
Date: Fri, 20 Jan 89 15:23:00 EST
From: decvax!cvbnet!giants.prime.com!tbardasz@decwrl.dec.com (Ted Bardasz)
Message-Id: <8901202023.AA04231@giants.uucp>
To: cvbnet!decvax!decwrl!SAIL.STANFORD.EDU!common-lisp@decwrl.dec.com
Subject: New Mail Address
Please change my mail address to:
decvax!tbardasz@cvbnet.prime.com
Thanks,
Ted Bardasz
∂23-Jan-89 0740 Common-Lisp-mailer Logical Operations on Numbers
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 23 Jan 89 07:40:00 PST
Received: from vax3.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
id AA01738; Mon, 23 Jan 89 10:40:36 est
Message-Id: <8901231540.AA01738@crash.cs.umass.edu>
Date: Sun, 22 Jan 89 12:18 EST
From: ELIOT@cs.umass.EDU
Subject: Logical Operations on Numbers
To: Common-Lisp@sail.stanford.EDU
X-Vms-To: IN%"Common-Lisp@sail.stanford.edu"
From: IN%"seb1525@draper.COM" 20-JAN-1989 12:12
Subj: LOGICAL OPERATIONS ON NUMBERS
From: SEB1525@mvs.draper.COM
To: common-lisp@SAIL.STANFORD.EDU
Isn't SUBSETP of A and B, where A and B are integers, implementable by
(eql B (logior A B))?
Yes. It is also (zerop (logandc2 A B)). However, these expressions
are not efficient. Suppose that the sets are large, hundreds or thousands
of elements. In this case A and B are going to be 'bignums', certainly
not FIXNUMS. Assuming that bignums are implemented so they can be
operated on as a series of chunks we have:
A = a1'a2'a3'...'an
B = b1'b2'b3'...'bn
SUBSET implemented directly is:
(AND[i=1..n] (%subset ai bi))
Where %subset operates on a single chunk. AND[i=1..n] is a short circuit
logical 'AND' operation. This requires n operations, and allocates NO new
memory.
SUBSET implemented as (eql B (logior A B)) requires n operations to compute
the logior, perhaps some overhead to normalize the new bignum,
plus n more operations to compute EQL, plus it allocates
memory to store max(A, B).
SUBSET implemented as (zerop (logandc2 A B)) requires n operations
to compute the logandc2, perhaps some overhead to normalize the new bignum,
and 1 operation to compute zero, plust it allocates memory to store
the intermediate result. This is slightly more efficient, because
ZEROP is microscopically more efficient that EQL. (ZEROP is FALSE for
all bignums. EQL has to look at them.) Furthermore the intermediate
result may be smaller than the intermediate result in the logior
construct.
I draw three conclusions from this.
(1) A naive computation of subset in Common Lisp requires approximately
twice the number of operations than it should, due to missing primitives.
(2) An optimizing compiler should try to recognize the SUBSET operation
and compile it efficiently. This may be difficult, because there are
at least two (and probably many) ways to encode this operation using the
existing Common Lisp primitives.
(3) For logical completeness, clarity and consistency of source programs
and efficient implementation of some algorithms Common Lisp should be
extended to include a logical subset operation for integers. The name
subsetp is already used (CLtL P.279) so I propose LOGSUBSETP with
semantics equivalent to:
(defun logsubsetp (a b)
(zerop (logandc2 a b)))
∂23-Jan-89 0946 Common-Lisp-mailer Order of "processing" of arguments
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Jan 89 09:45:51 PST
Received: from fafnir.think.com by Think.COM; Mon, 23 Jan 89 12:22:12 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 23 Jan 89 12:42:29 EST
Received: by verdi.think.com; Mon, 23 Jan 89 12:41:17 EST
Date: Mon, 23 Jan 89 12:41:17 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901231741.AA12978@verdi.think.com>
To: krulwich-bruce@yale.arpa
Cc: Common-Lisp@sail.stanford.edu
In-Reply-To: Bruce Krulwich's message of Thu, 12 Jan 89 12:49:19 EST <8901121749.AA18587@ATHENA.CS.YALE.EDU>
Subject: Order of "processing" of arguments
Date: Thu, 12 Jan 89 12:49:19 EST
From: Bruce Krulwich <krulwich-bruce@yale.arpa>
Michael Greenwald said:
>Actually, CLtL pg 61 says that the arguments and parameters are
>processed in order, from left to right. I don't know if "processed"
>implies "evaluated", but I always assumed (perhaps incorrectly) it did.
Guy Steele replied:
>I interpret this as referring to how the (fully evaluated) arguments
>are processed during lambda-binding, not to the order in which argument
>forms in a function call are evaluated. After all, the arguments referred
>to on page 61 might have come from a list given to APPLY, rather then
>from EVAL on a function call.
This seems vacuous to me. Does this mean that an implementation in which a
procedure entry point knows how many arguments its receiving (through a link
table, for instance, or simply by counting its arguments) and constructs a
REST-arg list before doing the binding of the required args is in violation of
CLtL because it processes the rightmost argument before the leftmost one?? I
hope not.
It seems to me that as long as actuals and formals are matched up correctly
there is no reason for the language specification to specify the order of the
"processing" of the arguments during lambda-binding.
Bruce Krulwich
krulwich@cs.yale.edu
The implementation need only behave "as if" it
processed them in that way.
It is always permissible to dye one's whiskers green
and then to use so large a fan that they cannot be seen.
--Guy
∂24-Jan-89 1317 Common-Lisp-mailer character proposal
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 24 Jan 89 13:16:41 PST
Date: Tue, 24 Jan 89 11:16:13 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890124.111613.baggins@almvma>
Subject: character proposal
Below are the minimum changes going into the character proposal.
This list was presented on a foil at the Hawaii meeting.
-- some minor corrections (bugs)
-- the registry document will:
-- be an appendix to the standard, not required
-- reference appropriate ISO standards (only)
-- character 'index' will be changed to character 'label' throughout
(labels are strings, not numeric values)
-- add the function char-ccs-value which takes a character object
and coded character set name and returns the value of
the character within that encoding.
-- add the function sgchar which is similar to sbchar but takes
a general-string object.
-- modify char-name, name-char, and #\name to accept character
names of the form 'registry:label'
As decided at the Hawaii meeting, the proposal will be voted on
at the March meeting (rather than by mail). In particular, there
were requests to partition the vote. If you have any specific
partition you would favor (eg. vote on external-width separately),
please let us know. (Note, the ballot is being split, not the
document). I'll probably send out a few informal ballots to get
a feeling for the partitioning as well identifing the controversial
items.
I will be revising the document and encourage any comments to
be sent immediately. I hope to send out a revision at the end of
this week. If there are additional comments (on the revision)
I will repeat this process if necessary to obtain a 'clean' version
for the March vote.
∂07-Feb-89 1759 Common-Lisp-mailer &environment extent
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 7 Feb 89 17:58:33 PST
Posted-Date: Tue, 07 Feb 89 17:55:58 PST
Message-Id: <8902080156.AA04251@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
id AA04251; Tue, 7 Feb 89 17:56:01 PST
To: common-lisp@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: &environment extent
Date: Tue, 07 Feb 89 17:55:58 PST
Sender: goldman@vaxa.isi.edu
Can someone tell me whether the ENVIRONMENT object passed as the second
parameter to a macro-expander function is specified to have DYNAMIC or
INDEFINITE extent?
Thanks,
Neil
∂12-Feb-89 1326 Common-Lisp-mailer File I/O
Received: from po2.andrew.cmu.edu by SAIL.Stanford.EDU with TCP; 12 Feb 89 13:26:36 PST
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA03940> for common-lisp@sail.stanford.edu; Sun, 12 Feb 89 16:21:55 EST
Received: via switchmail; Sun, 12 Feb 89 16:21:35 -0500 (EST)
Received: from kennettsq.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/q005/QF.EXxTFqy00jbbE0JEMo>;
Sun, 12 Feb 89 16:17:52 -0500 (EST)
Received: from kennettsq.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr13/dg1v/.Outgoing/QF.0XxTEhy00jbbI6jVMz>;
Sun, 12 Feb 89 16:16:30 -0500 (EST)
Received: from Version.6.25.N.CUILIB.3.45.SNAP.NOT.LINKED.kennettsq.andrew.cmu.edu.rt.r3
via MS.5.6.kennettsq.andrew.cmu.edu.rt_r3;
Sun, 12 Feb 89 16:16:29 -0500 (EST)
Message-Id: <MXxTEhy00jbbQ6jVFp@andrew.cmu.edu>
Date: Sun, 12 Feb 89 16:16:29 -0500 (EST)
From: David Greene <dg1v+@andrew.cmu.edu>
X-Andrew-Message-Size: 402+0
To: +dist+/afs/andrew.cmu.edu/usr0/postman/DistLists/Andrew-Hints.dl@andrew.cmu.edu,
bb+andrew.programming.lisp@andrew.cmu.edu,
common-lisp@sail.stanford.edu,
Outbound News <outnews+ext.nn.comp.lang.lisp@andrew.cmu.edu>
Subject: File I/O
I am trying to read various types of ascii data files into a standard common
LISP program (Ibuki Common Lisp). There are a number of ways to create streams
and such, but how can I test for an End Of File so that my read won't return an
error?
I have gone through Steele, but apparently the appropriate function has eluded
me. Thanks for any help.
-David
dg1v@andrew.cmu.edu
dpg@isl1.ri.cmu.edu
∂12-Feb-89 1353 Common-Lisp-mailer File I/O
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Feb 89 13:53:21 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 537730; Sun 12-Feb-89 16:51:03 EST
Date: Sun, 12 Feb 89 16:50 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: File I/O
To: dg1v+@andrew.cmu.edu
cc: Common-Lisp@SAIL.Stanford.EDU
In-Reply-To: <MXxTEhy00jbbQ6jVFp@andrew.cmu.edu>
Message-ID: <890212165052.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
There's not a separate function. Most reader functions (eg, READ and READ-LINE)
take an eof-p argument that says whether to signal an error if you read past
the end of a file. The default is T, but if you specify NIL then you can specify
a value to be returned when you have read past the end of file. Here are some
examples:
(DEFUN SHOW-FILE (FILE)
(WITH-OPEN-FILE (STREAM FILE)
(DO ((LINE (READ-LINE STREAM NIL NIL) (READ-LINE STREAM NIL NIL)))
((NOT LINE))
(WRITE-LINE LINE))))
(DEFUN GET-LISP-FORMS-FROM-FILE (FILE)
(WITH-OPEN-FILE (STREAM FILE)
(LET ((UNIQUE (LIST NIL)))
(DO ((FORM (READ STREAM NIL UNIQUE) (READ STREAM NIL UNIQUE))
(RESULT '() (CONS FORM RESULT)))
((EQ FORM UNIQUE) (NREVERSE RESULT))))))
By the way, the Common-Lisp list is -very- large (probably many hundreds of
recipients) and probably overkill for this kind of simple `how to' question.
Contacting your vendor or individually contacting just about any one of the
people you see contributing to this list would probably have gotten you the
same answer at lower cost to the community.
∂16-Feb-89 1402 Common-Lisp-mailer
Received: from NMFECC.ARPA by SAIL.Stanford.EDU with TCP; 16 Feb 89 14:02:13 PST
Received: from tuva.sainet.mfenet by ccc.mfenet with Tell via MfeNet ;
Thu, 16 Feb 89 13:59:35 PST
Date: Thu, 16 Feb 89 13:59:35 PST
From: POTHIERS%TUVA.SAINET.MFENET@NMFECC.ARPA
Message-Id: <890216135935.20800216@NMFECC.ARPA>
To: common-lisp@sail.stanford.edu
Subject: WANTED: Code Profiler
Date: Thu, 16-FEB-1989 14:57 MST
X-VMS-Mail-To: ARPA%"common-lisp%sail.stanford.edu@nmfecc.arpa"
Does any have (or know where I can get) a Common Lisp code profiler?
I'm interested in something that will give be number of invocations &/or
caller &/or timing information for all the user written functions
in my system. I would really like to profile some of our stuff
that uses PCL too. I don't mind having to hack at the code some to
make it suit my puposes.
Please direct any advice to me directly at:
pothiers%tuva.sainet@nmfecc.arpa
Thanks,
Steve Pothier
Science Applications International Corporation
Tucson
∂22-Feb-89 1330 Common-Lisp-mailer cs proposal part1
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:28:49 PST
Date: Wed, 22 Feb 89 00:13:28 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.001328.baggins@almvma>
Subject: cs proposal part1
\documentstyle{report} % Specifies the document style.
\pagestyle{headings}
\title{\bf
Extensions to Common LISP to Support International
Character Sets}
\author{
Michael Beckerle\thanks{Gold Hill Computers} \and
Paul Beiser\thanks{Hewlett-Packard} \and
Jerry Duggan\thanks{Hewlett-Packard} \and
Robert Kerns\thanks{Independent consultant} \and
Kevin Layer\thanks{Franz, Inc.} \and
Thom Linden\thanks{IBM Research, Subcommittee Chair} \and
Larry Masinter\thanks{Xerox Research} \and
David Unietis\thanks{Lucid, Inc.}
}
\date{February 21, 1989} % Deleting this command produces today's date.
\begin{document}
\maketitle % Produces the title.
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}
\tableofcontents
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newfont{\cltxt}{cmr10}
\newfont{\clkwd}{cmtt10}
\newcommand{\apostrophe}{\clkwd '}
\newcommand{\bq}{\clkwd\symbol{'22}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Introduction}
This is a proposal to the X3 J13 committee
for both extending and modifying the Common LISP
language definition to provide a standard basis for Common LISP
support of the variety of characters used to represent the
native languages of the international community.
This proposal was created by the Character Subcommittee of X3 J13.
We would like to acknowledge discussions with T. Yuasa and other
members of the JIS Technical Working Group,
comments from members of X3 J13,
and the proposals \cite{ida87},
\cite{linden87}, \cite{kerns87}, and \cite{kurokawa88} for
providing the motivation and direction for these extensions.
As all these documents and discussions were created
expressly for LISP standardization usage,
we have borrowed freely from their ideas as well as the texts
themselves.
This document is separated into two parts. The first part explains the
major language changes and their motivations. While intended as
commentary to a general audience, and not explicitly as
part of the standard document, the X3 J13 editor may
include sections at her/his discretion. The second part,
Appendix A, provides
the page by page set of editorial changes to \cite{steele84}.
\section{Objectives}
The major objectives of this proposal are:
\begin{itemize}
\item To provide a consistent, well-defined scheme allowing support
of both very large character sets and multiple character sets.
\footnote{The distinction between the terms {\em character repertoire}
and {\em coded character set} is made later. The usage
of the term {\em character set},
avoided after this introduction, encompasses both terms.}
Many software applications are intended for international use, or
have requirements for incorporation of language elements of multiple
native languages within a single application.
Also, many applications require specialized languages including,
for example, scientific and typesetting symbols.
In order
to ensure some portability of these applications, data expressed in
a mixture of these
languages must be treated uniformly by the
software language.
All character and string manipulations should operate uniformly,
regardless of the character set(s) of the character objects.
This applies to array indexing, readtable definitions, read
symbol construction and I/O operations.
\item To ensure efficient performance of string and character
operations.
Many native
languages, such as Japanese and Chinese, use character
sets which contain more characters than the Latin alphabet.
Supporting larger sized character sets frequently means employing
larger data fields to uniquely encode each character.
Common LISP implementations using
larger sized character sets can
incur performance penalties in terms
of space, time, or both.
The use of large and/or multiple character sets by an
implementation
implies the need for a more complex character type representation.
Given a more complex character representation, the efficiency
of language operations on characters (e.g. string operations)
could be affected.
\item To assure forward compatibility of the proposed model
and definition with existing Common LISP implementations.
Developers should not be required to re-write large amounts of either
LISP code or data representations in order to apply the proposed
changes to existing implementations.
The proposed changes should provide an easy
portability path for existing code to many possible implementations.
\end{itemize}
There are a number of issues, some under the general rubric of
internationalization, which this proposal does {\em not} cover.
Among these issues are:
\begin{itemize}
\item Time and date formats
\item Monetary formats
\item Numeric punctuation
\item Fonts
\item Lexicographic orderings
\item Right-to-left and bidirectional languages
\end{itemize}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Overview}
We use several terms within this document which
are new in the context of Common LISP.
Definitions for the following prominent
terms are provided for the reader's convenience.
A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font. This
corresponds to the mathematical notion of a {\em set}
\footnote{We avoid the term {\em character set} as it has been
(over)used in the context of character repertoire as well
as in the context of coded character set.}.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique {\em character label},
a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
There are numerous internationally standardized coded character
sets; for example, \cite{iso8859/1} and \cite{iso646}.
A character may be included in one or more character repertoires.
Similarly, a character may be included in one or more
coded character sets. For example, the Latin letter "A" is contained
in the coded character set standards: ISO 8859/1, ISO 8859/2,
ISO 6937/2, and others.
To universally identify each character, we define a unique
collection of repertoires called {\em character
registries} as a partitioning of all characters.
That is, each character is included
in one and only one character registry.
In Common LISP a {\em character} data object is identified by its
{\em character code}, a unique numerical code.
Each character code is composed from
a character registry and a character label.
Character data objects which are classified as {\em graphic},
or displayable, are each associated with a {\em glyph}. The
glyph is the visual representation of the character.
The primary purpose of introducing these terms is to provide a
consistent naming to Common LISP concepts which are related
to those found in ISO standardization of coded
character sets.
\footnote{The bibliography includes several relevant ISO
coded character set standards.}
They also serve as a demarcation between these
standardization activities. For example, while Common LISP is free to
define unique manipulation facilities for characters, registries
and coded character sets, it should
not define standard coded character sets nor standard character
registries.
A secondary purpose is to detach the language specification from
underlying hardware representation. From a language
specification viewpoint it is inconsequential whether
characters occupy one or more (8-bit) bytes or whether
a Common LISP implementation's
internal representation for characters is distinct from or identical
to any of the numerous
external representations (for example, the text interchange
representation \cite{iso6937/2}).
We specifically do not propose any standard coded character sets.
%----------------------------------------------------------------------
\section{Character Identity}
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers. That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
It is important to separate the notion of glyph from the notion of
character data object when defining a scheme under which issues of
identity can be rigorously decided by a computer language. Glyphs are
the visual aspects of characters, writable on surfaces, and sometimes
called 'graphics'. A language specification valid for more than a
narrow range of systems can only make assumptions about the existence
of {\em abstract} glyphs (for example, the Latin letter A) and not about
glyph variants (for example, the italicized Latin letter {\em A})
or characteristics of display devices. Thus, an important element of
this proposal is the removal of the {\em font} and {\em bits}
attributes from the language specification.
\footnote{These and other attributes may still be supported as
implementation-defined extensions.}
All functions
dealing with the {\em bits} and {\em font} attributes are either
removed or modified by this proposal.
The deleted functions and constants include:
{\em char-font-limit,
char-bits-limit,
int-char,
char-int,
char-bits,
char-font,
make-char,
char-control-bit,
char-meta-bit,
char-super-bit,
char-hyper-bit,
char-bit,
set-char-bit}.
The definition in \cite{steele84} of semi-standard characters has
been eliminated. This is replaced by a more uniform approach
to character naming with the introduction of character registries
(see below).
%----------------------------------------------------------------------
\section{Character Naming}
A Common LISP program must be able to name, compose and decompose
characters in a uniform, portable manner, independent of any
underlying representation. One possible composition is by
the pair $<$ coded character set standard, decimal representation $>$
\footnote{This syntax is for illustration only and is not being
proposed.}.
Thus, for example, one might compose the Latin 'A' with the pair
$<$ ISO8859/2-1987, 65 $>$,
$<$ ISO8859/6-1987, 65 $>$, or
$<$ ISO646-1983, 65 $>$, etc.. The difficulty here is two-fold.
First, there are several ways to compose the same character and
second, there may be multiple answers to
the question: {\em To what coded character set
does character object x belong?}.\footnote{Even
worse, the answer might change yearly.}
The identical problems occur if the pair
$<$ character repertoire standard, decimal representation $>$ is used.
\footnote{Existing ISO repertoires seem to be defined exclusively
in the context of coded character sets and not as standards
in their own right.}
The concept of character registry is introduced by this proposal
to resolve the problem of character naming, composition and
decomposition.
Each character is universally defined by the
pair $<$ character registry name, character label $>$. For this
to be a portable definition, it must have a standard meaning.
Thus we propose the formation of an ISO Working Group to
define an international
{\em Character Registry Standard}.
At this writing there is no existing Character Registry Standard nor
ISO Working Group organized to define such a standard.
\footnote{It is the intention of X3 J13 to promote and adopt
an eventual ANSI or ISO Character Registry Standard. In particular, we
acknowledge that X3 J13 is {\em not} the appropriate forum to
define the standard. We believe
it is a required component of all programming languages
providing support for international characters.}
Common LISP character codes are composed from a character registry and
a character label. The convention by which a character label and
character registry compose a character code is implementation
dependent.
We introduce new functions {\clkwd find-char, char-registry-name,} and
{\clkwd char-label} to
compose and decompose character objects. We also extend the
{\clkwd characterp} predicate to
support testing
membership of a character in a given character registry.
\footnote{
For example,
testing membership in the Japanese Katakana character registry.
}
A global variable {\clkwd *all-character-registry-names*}
is added to
support application determination of supported character registries.
The naming and content of the standard character registries
is left unspecified by this proposal.
\footnote{The only constraint is that character registries be
named using only {\clkwd standard-p} characters.}
Below are some candidate character registry names:
\begin{itemize}
\item Arabic
\item Armenian
\item Bo-po-mo-fo
\item Control (meaning the collection of standard text communication
control codes)
\item Cyrillic
\item Georgian
\item Greek
\item Hangul
\item Hebrew
\item Hiragana
\item Japanese-Punctuation
\item Kanji
\item Katakana
\item Latin
\item Latin-Punctuation
\item Mathematical
\item Pattern
\item Phonetic
\item Technical
\end{itemize}
The list above is provided as a starting point for discussion
and is not intended to be representative
nor exhaustive. The Common LISP language definition does not
depend on these names nor any specific content (for example:
Where should the plus sign appear?). It is application
programs which require a reliable definition of the
registry names and their constituents. The Common LISP language
definition imposes the framework for constructing and manipulating
character objects.
The proposed ISO Character Registry Standard is fixed;
an implementation may not extend a standard registry's
constituent set of characters beyond the
standard definition.
An implementation may provide support for all or part of any
character registry
and may provide new character registries which include characters
having unique semantics (i.e. not defined in any standard
character registry).
Implementation registries must be uniquely
named using only {\clkwd standard-p} characters.
An implementation must document the registries it supports.
For each registry supported the documentation must include
at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions.
\item Reader Canonicalization.
\item Effect of character predicates.
In particular,
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O. In particular, the
coded character sets
\footnote{For example, ISO8859/1-1987.} and
external encoding schemes
\footnote{For example, {\em Xerox System Integration Character
Code Standard}\cite{xerox87}.}
supported are documented.
\end{itemize}
Which coded character sets and encoding schemes
are supported by the overall computing system, the
details of the mapping of glyphs to characters
to character codes are
left unspecified by Common LISP.
The diversity of glyph sets and coded character
set conventions in use worldwide and the desirability
of allowing Common LISP applications
to portabily manipulate symbolic elements from many
languages, perhaps simultaneously, mandate such a flexible approach.
%----------------------------------------------------------------------
\section{Hierarchy of Types}
Providing support for extensive character repertoires may
impact Common LISP implementation performance in terms
of space, time, or both.
\footnote{This does not apply to all implementations.
Unique hardware support and user community requirements must
be taken into consideration.}
In particular, many existing
implementations support variants of the ISO 8859/1 standard.
Supporting large
repertoires argues for a multi-byte internal representation
for each character, even if an application primarily (or exclusively)
uses the ISO 8859/1 characters.
This proposal extends the definition of the character and string
type hierarchy to include specialized subtypes
of character and string. An implementation is free to associate
compact internal representation tailored to each subtype.
The {\clkwd string} type specifier, when used for object
creation, for example in {\clkwd make-sequence},
is defined to mean the most general string subtype supported
by the implementation (similarily for the {\clkwd simple-string}
type specifier). This definition emphasizes portability
of existing Common LISP applications to international
character environments over performance. Applications emphasizing
efficiency of text processing in non-international environments
will require some modification to utilize subtypes with
compact internal representations.
It has been suggested that either a single type is
sufficient to support international characters,
or that a hierarchy of types could be used, in a manner
transparent to the user. A desire to provide flexibility which
encourages implementations to support international
characters without compromising application efficiency
led us to accept the need for more than one type.
We believe that these choices reflect a minimal
modification of this aspect of the type system, and that
exposing the types for string and character construction while
requiring uniform treatment for characters otherwise
is the most reasonable approach.
\subsection{Character Type}
The following type specifier is added as a subtype
of {\clkwd character}:
\begin{itemize}
\item {\clkwd base-character}
\end{itemize}
An implementation may support additional subtypes of {\clkwd character}
which may or may not be supertypes of {\clkwd base-character}.
In addition, an implementation may define {\clkwd base-character}
as equivalent to {\clkwd character}.
Characters of type {\clkwd base-character} are referred to as
{\em base characters}. Characters of type {\clkwd
(and character (not base-character))}
are referred to as {\em extended characters}.
The base characters are
distinguished in the following respects:
\begin{itemize}
\item
The standard characters are a subrepertoire of the base characters.
The selection of base characters which are not standard characters
is implementation defined.
\item
Only members of the base character repertoire
can be elements of a base string.
\item
The base characters are, in general, the default characters for I/O
operations.
\end{itemize}
No upper bound is specified for the number of glyphs in the base
character repertoire--that
is implementation dependent. The lower bound is 96, the
number of standard characters defined for Common LISP.
\footnote{Or, in contrast, the base repertoire may include all
implementation supported characters.}
The distinction of base characters is largely a pragmatic
choice. It permits efficient handling of common situations, is
in some sense privileged for host system I/O, and can serve as an
intermediate basis for portability, less general than the standard
characters, but possibly more useful across a narrower range of
implementations.
Many computers have some "base" character representation which
is a function of hardware instructions for dealing with characters,
as well as the organization of the file system. The base character
representation is likely to be the smallest transaction unit permitted
for text file and terminal I/O operations. On a system with a record
based I/O paradigm, the base character representation is likely to
be the smallest record quantum. On many computer systems,
this representation is a byte.
However, there are often multiple
coded character sets supportable on a
computer, through the use of special display and entry hardware, which
are varying interpretations of the basic system character
representation. For example, ISO 8859/1 and ISO 6937/2 are two
different interpretations of the same 1-byte code representations.
Many countries have their own glyph-to-code mappings for 1-byte
character codes addressing the special requirements of national
languages. Differentiating between these, without reference to
display hardware, is a matter of convention, since they all use the
same set of code representations. When a single byte is not enough,
two or more bytes are sometimes used for character encoding. This
makes character handling even more difficult on machines where the
natural representation size is a byte, since not only is the semantic
value of a character code a matter of convention, which may vary
within the same computing system, but so is the identification of a
set of bits as a complete character code.
It is the intention of this proposal that the composition of
base characters is typically
determined by the code capacity of the natural file system and I/O
transaction representations, and the assumed display glyphs should be
those of the terminals most commonly employed.
There are several advantages to this scheme. Internal representation
of strings of just base characters can be more compact than
strings including extended characters.
Source programs are likely to consist predominantly of base characters
since the standard characters are a subset of the base character
repertoire. Parsing of pure base character text
can be more efficient than parsing of text including
extended characters.
I/O can be performed more simply
with base characters.
The standard characters are the 96 characters used in the Common LISP
definition {\bf or their equivalents}.
This was the Common LISP \cite{steele84} definition, but
{\em equivalents} is a vague term.
The standard characters are not defined by their glyphs, but by their
roles within the language. There are two aspects to the roles of the
standard characters: one is their role in reader and format control
string syntax; the second is their role as components of the names of
all Common LISP
functions, macros, constants, and global variables. As
long as an implementation chooses 96 glyphs
and treats those 96 in a manner consistent with
the language's specification for the standard characters (e.g.
the naming of functions), it doesn't matter what glyphs the I/O
hardware uses to represent those characters: they are the standard
characters. Any program or
data text written wholly in those characters
is portable through simple code conversion.
\footnote{For example, the currency glyph, \$ , might be replaced
uniformly by the currency glyph available on a particular display.}
Additional
mechanisms, such as in \cite{linden87}, which support establishment of
equivalency between otherwise distinct characters are not excluded by
this proposal.
\footnote{We believe this is an important issue but it requires
additional implementation experience. We also encourage
new proposals from JIS and ISO LISP Working Groups on this issue.}
\subsection{String Type}
The {\clkwd string} type
is defined as
a vector of characters. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype of character. Similarly, a simple
string is a specialized simple vector whose elements are of type
{\clkwd character} or a subtype of character. The following string
subtypes are
distinguished with standardized names: {\clkwd base-string},
{\clkwd general-string}, {\clkwd simple-base-string}, and
{\clkwd simple-general-string}.
All strings which are not base strings
are referred to as {\em extended strings}.
A base string can only contain base characters.
{\clkwd general-string} is equivalent to {\clkwd (vector character)}
and can contain any implementation supported base or extended characters,
in any mixture.
All Common LISP functions defined to operate on strings treat
base and extended strings uniformly with the following
caveat: for any function which inserts a character into a string, it
is an error to insert an extended character
into a base string.
\footnote{An implementation may, optionally, provide automatic
coersion to an extended string.}
An implementation may support string subtypes in addition
to {\clkwd base-string} and
{\clkwd general-string}.
For example, a hypothetical
implementation supporting Arabic and Cyrillic character registries
might provide as extended characters:
\begin{itemize}
\item {\clkwd general-string} -- may contain Arabic, Cyrillic or
base characters in any mixture.
\item {\clkwd region-specialized-string} -- may contain installation
selected repertoire (Arabic/Cyrillic) or base characters in any
mixture.
\item {\clkwd base-string} -- may contain base characters
\end{itemize}
Though, clearly, portability of applications using
{\clkwd region-specialized-string} is limited, a performance
advantage might argue for its use.
\footnote{{\clkwd region-specialized-string} is used here for
illustration only; it is not being proposed as a standardized
string subtype.}
Alternatively,
an implementation
supporting a large base character repertoire
including, say, Japanese Kanji may define
{\clkwd base-character}
as equivalent to {\clkwd character}.
We expect that applications sensitive to the performance
of character handling in some host environments will
utilize the string subtypes to provide performance
improvement. Applications with emphasis on international
portability will likely utilize only {\clkwd general-string}s.
The {\clkwd coerce} function is extended to
allow for explicit coercion between base strings and extended strings.
It is an error to coerce an extended character to a base character.
During reader
construction of symbols, if all the characters
in the symbol's name are of type {\clkwd base-character},
then the name of the symbol may be stored as a base string.
Otherwise it will be stored as an extended string.
The base string type allows for more compact representation of strings
of base characters, which are likely to predominate in any system.
Note that in any particular implementation the base characters
need not be the
most compactly representable, since others might have
a smaller repertoire.
However, in most implementations base strings are
likely to be more space efficient than extended strings.
%----------------------------------------------------------------------
\section{Streams and System I/O}
A lot of the work of ensuring that a
Common LISP implementation operates correctly in a
multiple coded character set environment must be performed by
the I/O interface.
The system I/O interface, abstracted in
Common LISP as streams, is responsible
for ensuring that text input from outside LISP is properly mapped
into character objects internally, and that the inverse mapping
is performed on output. It is beyond the scope of a language
definition to specify the details of this operation, but options
are specified which allow runtime indication from the user as to
what coded character sets a stream uses, and how the mappings
should be done. It is expected that implementations will provide
reasonable defaults and invocation options to accommodate desired use
at an installation.
One keyword argument is proposed as an addition to {\clkwd open}:
\begin{itemize}
\item {\clkwd :external-coded-character-format}
whose value would be:
\begin{itemize}
\item
A name or list of names indicating an implementation recognized
scheme for representing 1 or more coded character sets.
\footnote{
For example, the so/si convention used by IBM on 370
machines could be selected by a list including
the name {\clkwd :ibm-shift-delimited}.
The run-encoding convention defined by XEROX could be
selected by {\clkwd :xerox-run-encoded}.
The convention based on
ASCII which uses leading bit patterns to distinguish two-byte codes
from one-byte codes could be selected by
{\clkwd :ascii-high-byte-delimited}.
}
As many coded character set names must be provided as the
implementation requires for that external coding convention.
\footnote{
For example, if {\clkwd :ibm-shift-delimited} were the
argument, two
coded character set specifiers would have to be provided.
}
\end{itemize}
\end{itemize}
These arguments are provided for input, output, and
bidirectional streams.
It is an error to try to write a character other than a
member of the specified coded character sets
to a stream. (This excludes the
\#$\backslash${\clkwd Newline} character.
Implementations must provide appropriate line division behavior
for all character streams.)
An implementation supporting multiple coded character sets
must allow for the external
representation of characters to be separately (and perhaps
multiply) specified to {\clkwd open},
since there can be circumstances under
which more than one external representation for characters
is in use, or more than one coded character set
is mixed together in an
external representation convention.
In addition to supporting conversion at the system interface, the
language must allow user programs to determine how much space data
objects will require when output in whichever external representations
are available.
The new function {\clkwd external-coded-string-length}
takes a character
or string object as its required argument. It also takes an optional
{\em output-stream}.
It returns the number of implementation-defined
representation units
\footnote{
Often the same as the storage width of a base character, usually a byte.
}
required to externally store that object, using the
representation convention associated with the stream.
If the object cannot be represented in
that convention, the function returns {\clkwd nil}.
This function is necessary
to determine if strings can be written to fixed length
fields in databases or terminal screen templates. Note that this
function does not
address the problem of calculating
screen width of strings printed in proportional fonts.
Related to the I/O interface,
we also introduce the function {\clkwd char-ccs-value}
which takes a character object and a coded character set name
(eg. {\clkwd :ISO8859/1-1987}) and returns the encoding of
the character within the coded character set.
%----------------------------------------------------------------------
%----------------------------------------------------------------------
∂22-Feb-89 1332 Common-Lisp-mailer cs proposal revisions
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:32:18 PST
Date: Wed, 22 Feb 89 00:36:12 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.003612.baggins@almvma>
Subject: cs proposal revisions
I've sent out a revised cs document for your review. It reflects
a number of your comments from the Hawaii meeting and over the
net. The larger changes were:
-- The 'depreciated' appendix is eliminated. I re-introduced
the list of implementation-dependent attribute support
items into the document proper. The other items in
appendix B were simply eliminated.
-- The functions sbchar and sgchar are eliminated. In general,
the comments indicate that case discrimination by schar
does not introduce a substantial performance penalty.
-- Character registry names and constituents are NOT defined by
Common LISP. The proposal defines only the framework for
composition and decomposition of characters. The naming
of registries and definition of their constituents are
left completely as an ISO standard activity.
-- Character registry names and constituents are NOT defined by
Common LISP. The proposal defines only the framework for
composition and decomposition of characters. The naming
of registries and definition of their constituents are
left completely as an ISO standard activity.
Please send comments to the X3J13 mailing list. If time allows
and it seems needed, I will send out another revision in time to
allow for an actual vote at the March meeting. A straw vote list
will follow shortly.
Regards,
Thom
∂22-Feb-89 1332 Common-Lisp-mailer cs proposal part 2
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:30:31 PST
Date: Wed, 22 Feb 89 00:14:09 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.001409.baggins@almvma>
Subject: cs proposal part 2
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newcommand{\edithead}{\begin{tabular}{l p{3.95in}}
\multicolumn{2}{l} }
\newcommand{\csdag}{\bf$\Rightarrow$\ddag}
\newcommand{\editstart}{}
\newcommand{\editend}{\\ & \end{tabular}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\appendix
\chapter{Editorial Modifications to CLtL}
The following sections specify the editorial changes needed in
CLtL to support the proposal. Section/subsection numbers and titles
match those found in \cite{steele84}. The notation
{\csdag x (pn, function)} denotes a reference to paragraph x within the
subsection (we count each individual example or metastatement
as 1 paragraph of text). Also, {\bf (pn, function)}, or simply
{\bf (pn)} is included as an additional
aid to the reader indicating the page number and function modified.
When an entire paragraph is deleted,
the first few words of the paragraph is noted.
If a section or paragraph of CLtL is {\em not} referenced,
no editorial changes are required to support this proposal.
\footnote{This may be an over optimistic statement since the changes
are fairly pervasive. The editor should take the sense of
Chapter 1 into account in resolving any discrepancies.}
%----------------------------------------------------------------------
\setcounter{section}{1}
\section{Data Types} % 2
%----------------------------------------------------------------------
\edithead {\csdag 8 (p12)}
\editstart
\\ \bf replace &
\cltxt
provides for a
rich character set, including ways to represent characters of various
type styles.
\\ \bf with &
\cltxt
provides support for international language characters as well
as characters used in specialized arenas, eg. mathematics.
\editend
\setcounter{subsection}{1}
\subsection{Characters} % 2.2.
\edithead {\csdag 1 (p20)}
\editstart
\\ \bf replace &
\cltxt
Characters are represented as data objects of type {\clkwd character}.
There are two subtypes of interest, called
{\clkwd standard-char} and {\clkwd string-char}.
\\ \bf with &
\cltxt
Characters are represented as data objects of type
{\clkwd character}.
\editend
\\
\edithead {\csdag 2 (p20)}
\editstart
\\ \bf replace &
\cltxt
This works well enough for printing characters. Non-printing
characters
\\ \bf with &
\cltxt
This works well enough for graphic characters. Non-graphic
characters
\editend
\subsubsection{Standard Characters} % 2.2.1.
\edithead {\csdag 1 before (p20)}
\editstart
\\ \bf insert &
\cltxt
A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique label, a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
\\ &
Common LISP requires all implementations to support a {\em standard}
character subrepertoire. Typically, an implementation
incorporates the standard
characters as a subset of a larger repertoire corresponding
to a frequently used set of characters, or base coded character
set.
The term {\em base character repertoire} refers to
the collection of characters represented by
the base coded character set.
\editend
\\
\edithead {\csdag 1 before (p20)}
\editstart
\\ \bf insert &
\cltxt
The {\clkwd base-character} type is defined as a subtype of
{\clkwd character}. A {\clkwd base-character}
object can contain any member of the base character repertoire.
Objects of type
{\clkwd (and character (not base-character))} are referred to
as {\em extended characters}.
\editend
\\
\edithead {\csdag 1 (p20)}
\editstart
\\ \bf delete &
\cltxt
Common LISP defines a "standard character set" ...
\editend
\\
\edithead {\csdag 1 (P20)}
\editstart
\\ \bf new &
\cltxt
The Common LISP
standard character subrepertoire consists of
a newline \#$\backslash${\clkwd Newline}, the
graphic space character \#$\backslash${\clkwd Space},
and the following additional
ninety-four graphic characters or their equivalents:
\editend
\\
\edithead {\csdag 2 (p21)}
\editstart
\\ \bf delete &
\cltxt
! " \# ...
\editend
\\
\edithead {\csdag 2 new (p21)}
\editstart
\\ &
{\bf Common LISP Standard Character Subrepertoire}
\editend
\footnote{\cltxt \#$\backslash${\clkwd Space}
and \#$\backslash${\clkwd Newline} are omitted.
graphic labels and descriptions are from ISO 6937/2.
The first letter of the graphic label categorizes the
character as follows: L - Latin, N - Numeric, S - Special
.}
\\
{\small \begin{tabular}{||l|c|l||l|c|l||} \hline
Label & Glyph & Name or description
& Label & Glyph & Name or description
\\ \hline
LA01 & a & small a
& ND01 & 1 & digit 1
\\ \hline
LA02 & A & capital A
& ND02 & 2 & digit 2
\\ \hline
LB01 & b & small b
& ND03 & 3 & digit 3
\\ \hline
LB02 & B & capital B
& ND04 & 4 & digit 4
\\ \hline
LC01 & c & small c
& ND05 & 5 & digit 5
\\ \hline
LC02 & C & capital C
& ND06 & 6 & digit 6
\\ \hline
LD01 & d & small d
& ND07 & 7 & digit 7
\\ \hline
LD02 & D & capital D
& ND08 & 8 & digit 8
\\ \hline
LE01 & e & small e
& ND09 & 9 & digit 9
\\ \hline
LE02 & E & capital E
& ND10 & 0 & digit 0
\\ \hline
LF01 & f & small f
& SC03 & \$ & dollar sign
\\ \hline
LF02 & F & capital F
& SP02 & ! & exclamation mark
\\ \hline
LG01 & g & small g
& SP04 & " & quotation mark
\\ \hline
LG02 & G & capital G
& SP05 & \apostrophe & apostrophe
\\ \hline
LH01 & h & small h
& SP06 & ( & left parenthesis
\\ \hline
LH02 & H & capital H
& SP07 & ) & right parenthesis
\\ \hline
LI01 & i & small i
& SP08 & , & comma
\\ \hline
LI02 & I & capital I
& SP09 & \_ & low line
\\ \hline
LJ01 & j & small j
& SP10 & - & hyphen or minus sign
\\ \hline
LJ02 & J & capital J
& SP11 & . & full stop, period
\\ \hline
LK01 & k & small k
& SP12 & / & solidus
\\ \hline
LK02 & K & capital K
& SP13 & : & colon
\\ \hline
LL01 & l & small l
& SP14 & ; & semicolon
\\ \hline
LL02 & L & capital L
& SP15 & ? & question mark
\\ \hline
LM01 & m & small m
& SA01 & + & plus sign
\\ \hline
LM02 & M & capital M
& SA03 & $<$ & less-than sign
\\ \hline
LN01 & n & small n
& SA04 & = & equals sign
\\ \hline
LN02 & N & capital N
& SA05 & $>$ & greater-than sign
\\ \hline
LO01 & o & small o
& SM01 & \# & number sign
\\ \hline
LO02 & O & capital O
& SM02 & \% & percent sign
\\ \hline
LP01 & p & small p
& SM03 & \& & ampersand
\\ \hline
LP02 & P & capital P
& SM04 & * & asterisk
\\ \hline
LQ01 & q & small q
& SM05 & @ & commercial at
\\ \hline
LQ02 & Q & capital Q
& SM06 & [ & left square bracket
\\ \hline
LR01 & r & small r
& SM07 & $\backslash$ & reverse solidus
\\ \hline
LR02 & R & capital R
& SM08 & ] & right square bracket
\\ \hline
LS01 & s & small s
& SM11 & \{ & left curly bracket
\\ \hline
LS02 & S & capital S
& SM13 & $|$ & vertical bar
\\ \hline
LT01 & t & small t
& SM14 & \} & right curly bracket
\\ \hline
LT02 & T & capital T
& SD13 & \bq & grave accent
\\ \hline
LU01 & u & small u
& SD15 & $\hat{ }$ & circumflex accent
\\ \hline
LU02 & U & capital U
& SD19 & $\tilde{ }$ & tilde
\\ \hline
LV01 & v & small v
& & &
\\ \hline
LV02 & V & capital V
& & &
\\ \hline
LW01 & w & small w
& & &
\\ \hline
LW02 & W & capital W
& & &
\\ \hline
LX01 & x & small x
& & &
\\ \hline
LX02 & X & capital X
& & &
\\ \hline
LY01 & y & small y
& & &
\\ \hline
LY02 & Y & capital Y
& & &
\\ \hline
LZ01 & z & small z
& & &
\\ \hline
LZ02 & Z & capital Z
& & &
\\
\hline
\end{tabular} }
\\
\edithead {\csdag 3 (p21)}
\editstart
\\ \bf delete &
\cltxt
@ A B C...
\editend
\\
\edithead {\csdag 4 (p21)}
\editstart
\\ \bf delete &
\cltxt
\bq a b c...
\editend
\\
\edithead {\csdag 5 (p21)}
\editstart
\\ \bf delete &
\cltxt
The Common LISP Standard character set is apparently ...
\editend
\\
\edithead {\csdag 6 (p21)}
\editstart
\\ \bf replace &
\cltxt
Of the ninety-four non-blank printing characters
\\ \bf with &
\cltxt
Of the ninety-five graphic characters
\editend
\\
\edithead {\csdag 9 (p21)}
\editstart
\\ \bf delete &
\cltxt
The following characters are called ...
\editend
\\
\edithead {\csdag 10 (p21)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd \#$\backslash$Backspace \#$\backslash$Tab } ...
\editend
\\
\edithead {\csdag 11 (p21)}
\editstart
\\ \bf delete &
\cltxt
Not all implementations of Common ...
\editend
\subsubsection{Line Divisions} % 2.2.2.
\edithead {\csdag 6 (p22)}
\editstart
\\ \bf replace &
\cltxt
a two-character sequence, such as
{\clkwd \#$\backslash$Return } and then
{\clkwd \#$\backslash$Newline },
is not acceptable,
\\ \bf with &
\cltxt
a two-character sequence is not acceptable,
\editend
\\
\edithead {\csdag 8 (p22)}
\editstart
\\ \bf delete &
\cltxt
Implementation note: If an implementation uses ...
\editend
\subsubsection{Non-standard Characters} % 2.2.3.
\edithead {\csdag delete entire section (p23)}
\editstart
\editend
\subsubsection{Character Attributes} % 2.2.4.
\edithead {\csdag 0 section heading (p23)}
\editstart
\\ \bf replace &
\cltxt
Character Attributes
\\ \bf with &
\cltxt
Character Identity
\editend
\\
\edithead {\csdag 1 through 8 (p23)}
\editstart
\\ \bf delete all paragraphs&
\cltxt
Every object of type {\clkwd character} ...
\editend
\\
\edithead {\csdag 1 (p23)}
\editstart
\\ \bf new &
\cltxt
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers. That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
\\ &
Common LISP
characters are partitioned into a unique collection of
repertoires called {\em
character registries}. That is, each character is included
in one and only one character registry.
\\ &
Character codes are composed from a character registry and a
character label. The convention by which a character registry and
character label compose a character code is implementation
dependent.
\editend
\subsubsection{String Characters} % 2.2.5.
\edithead {\csdag delete entire section (p23)}
\editstart
\editend
\setcounter{subsection}{4}
\subsubsection{Character Registries} % 2.2.5.
\edithead {\csdag new section (p23)}
\editstart
\\ \bf new &
\cltxt
An implementation must document the registries it supports.
Registries must be uniquely
named using only {\clkwd standard-p} characters.
For each registry supported,
an implementation must define the individual characters supported
including at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions.
\item Reader Canonicalization.
\item Effect of character predicates.
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O. In particular, the
coded character set standards
\footnote{For example, ISO8859/1-1987.} and
external encoding schemes
which are supported must be specified.
\end{itemize}
\editend
\subsection{Symbols} % 2.3.
\edithead {\csdag 12 (p25)}
\editstart
\\ \bf replace &
\cltxt
A symbol may have uppercase letters, lowercase letters, or both
in its print name.
\\ \bf with &
\cltxt
A symbol may have characters from any supported character registry
in its print name.
It may have uppercase letters, lowercase letters, or both.
\editend
\setcounter{subsection}{4}
\subsection{Arrays}
\subsubsection{Vectors}
\edithead {\csdag 6 (p29)}
\editstart
\\ \bf replace &
\cltxt
All implementations provide specialized arrays for the cases when
the components are characters (or rather, a special subset of the
characters);
\\ \bf with &
\cltxt
All implementations provide specialized arrays for the cases when
the components are characters (or optionally, special subsets of
the characters);
\editend
\subsubsection{Strings}
\edithead {\csdag 1 (p30)}
\editstart
\\ \bf replace &
\cltxt
A string is simply a vector of characters. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd string-char}.
\\ \bf with &
\cltxt
A string is simply a vector of characters. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype
of character.
\editend
\setcounter{subsection}{14}
\subsection{Overlap, Inclusion, and Disjointness of Types} % 2.15.
\edithead {\csdag 14 (p34)}
\editstart
\\ \bf replace &
\cltxt
The type {\clkwd standard-char} is a subtype of {\clkwd string-char};
{\clkwd string-char} is a subtype of {\clkwd character}.
\\ \bf with &
\cltxt
The type {\clkwd base-character} is a subtype of
{\clkwd character}.
The type {\clkwd string-char} is implementation defined as either
{\clkwd base-character} or {\clkwd character}.
\editend
\\
\edithead {\csdag 15 (p34)}
\editstart
\\ \bf replace &
\cltxt
The type {\clkwd string} is a subtype of {\clkwd vector},
for {\clkwd string} means {\clkwd (vector string-char)}.
\\ \bf with &
\cltxt
The type {\clkwd string} is a subtype of {\clkwd vector},
{\clkwd string} consists of vectors specialized by subtypes of
{\clkwd character}.
\editend
\\
\edithead {\csdag 15 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd base-string} means
{\clkwd (vector base-character)}.
\editend
\\
\edithead {\csdag 15 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd general-string} means
{\clkwd (vector character)} and is a subtype of {\clkwd string}.
\editend
\\
\edithead {\csdag 20 (p34)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd (simple-array string-char (*))};
\\ \bf with &
\cltxt
{\clkwd (and string simple-array)};
\editend
\\
\edithead {\csdag 20 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd simple-base-string} means
{\clkwd (simple-array base-character (*))} and
is the most efficient string which can hold
the standard characters. {\clkwd simple-base-string}
is a subtype of {\clkwd base-string}.
\editend
\\
\edithead {\csdag 20 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd simple-general-string} means
{\clkwd (simple-array character (*))}.
{\clkwd simple-general-string}
is a subtype of {\clkwd general-string}.
\editend
\\
\edithead {\csdag 22 after (p34)}
\editstart
\\ \bf replace &
\cltxt
The type {\clkwd simple-string} is a subtype of
{\clkwd string}. (Note that although
{\clkwd string}
is a subtype of {\clkwd vector, simple-string} is not
a subtype of {\clkwd simple-vector}.
\\ \bf with &
\cltxt
The type {\clkwd simple-string} is a subtype of
{\clkwd string}, {\clkwd simple-string} consists of
simple vectors specialized by subtypes of
{\clkwd character}. (Note that although
{\clkwd string}
is a subtype of {\clkwd vector, simple-string} is not
a subtype of {\clkwd simple-vector}.
\editend
%----------------------------------------------------------------------
\setcounter{section}{3}
\section{Type Specifiers} % 4
%----------------------------------------------------------------------
\setcounter{subsection}{1}
\subsection{Type Specifier Lists} % 4.2.
\edithead {\csdag 8 Table 4-1 (alphabetic list) (p43)}
\editstart
\\ \bf remove &
\\ &
\cltxt
{\clkwd standard-char}
\\ &
{\clkwd string-char}
\editend
\\
\edithead {\csdag 8 Table 4-1 (alphabetic list) (p43)}
\editstart
\\ \bf insert &
\\ &
\cltxt
{\clkwd base-character}
\\ &
{\clkwd base-string}
\\ &
{\clkwd general-string}
\\ &
{\clkwd simple-base-string}
\\ &
{\clkwd simple-general-string}
\editend
\setcounter{subsection}{2}
\subsection{Predicating Type Specifiers} % 4.3.
\edithead {\csdag 2 (p43)}
\editstart
\\ \bf delete &
\cltxt
As an example, the entire ...
\editend
\\
\edithead {\csdag 3 delete example (p43)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (deftype string-char () } ...
\editend
\setcounter{subsection}{4}
\subsection{Type Specifiers That Specialize} % 4.5.
\edithead {\csdag 5 after (p46)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd (character {\em repertoire})}
\\ &
This denotes a character type specialized to members
of the specified repertoire. {\em Repertoire} may be
{\clkwd :base} or {\clkwd :standard} or any supported
character registry name or a list of names.
\editend
\setcounter{subsection}{5}
\subsection{Type Specifiers That Abbreviate} % 4.6.
\edithead {\csdag 20 (p49)}
\editstart
\\ \bf replace &
\cltxt
Means the same as {\clkwd (array string-char ({\em size}))}: the set of
strings of
the indicated size.
\\ \bf with &
\cltxt
Means the union of the vector types specialized by subtypes of
character
and the indicated size.
For the purpose of object creation, it is equivalent to
{\clkwd (general-string ({\em size}))}.
\editend
\\
\edithead {\csdag 23 (p49)}
\editstart
\\ \bf replace &
\cltxt
Means the same as {\clkwd (simple-array string-char ({\em size}))}: the
set of simple strings of the indicated size.
\\ \bf with &
\cltxt
Means the union of the simple vector types specialized by subtypes of
character and the indicated size.
For the purpose of object creation, it is equivalent to
{\clkwd (simple-general-string ({\em size}))}.
\editend
\\
\edithead {\csdag 23 after (p49)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd (base-string {\em size})}
\\ &
Means the same as {\clkwd (array base-character ({\em size}))}: the
set of base strings of the indicated size.
\\ &
{\clkwd (simple-base-string {\em size})}
\\ &
Means the same as {\clkwd (simple-array base-character ({\em size}))}:
the set of simple base strings of the indicated size.
\editend
\\
\edithead {\csdag 23 after (p49)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd (general-string {\em size})}
\\ &
Means the same as {\clkwd (array character ({\em size}))}: the
set of base strings of the indicated size.
\\ &
{\clkwd (simple-general-string {\em size})}
\\ &
Means the same as
{\clkwd (simple-array general-character ({\em size}))}:
the set of simple general strings of the indicated size.
\editend
\setcounter{subsection}{7}
\subsection{Type Conversion Function} % 4.8.
\edithead {\csdag 6 (p51)}
\editstart
\\ \bf replace &
\cltxt
Some strings, symbols, and integers may be converted to
characters. If {\em object} is a string of length 1,
then the sole element of the print name is returned.
If {\em object} is a symbol whose print name is of length
1, then the sole element of the print name is returned.
If {\em object} is an integer {\em n}, then {\clkwd (int-char }
{\em n}{\clkwd )} is returned. See {\clkwd character}.
\\ \bf with &
\cltxt
Some strings amd symbols may be converted to
characters. If {\em object} is a string of length 1,
then the sole element of the print name is returned.
If {\em object} is a symbol whose print name is of length
1, then the sole element of the print name is returned.
See {\clkwd character}.
\editend
\\
\edithead {\csdag 6 after (p52)}
\editstart
\\ \bf insert &
\begin{itemize}
\cltxt
\item Any string subtype may be converted to any other string
subtype, provided the new string can contain all actual
elements of the old string. It is an error if it cannot.
\end{itemize}
\editend
%----------------------------------------------------------------------
\setcounter{section}{5}
\section{Predicates} % 6
%----------------------------------------------------------------------
\edithead {\csdag 2 (p71)}
\editstart
\\ \bf replace &
\cltxt
but {\clkwd standard-char} begets {\clkwd standard-char-p}
\\ \bf with &
\cltxt
but {\clkwd bit-vector} begets {\clkwd bit-vector-p}
\editend
\setcounter{subsection}{1}
\subsection{Data Type Predicates} % 6.2.
\setcounter{subsubsection}{1}
\subsubsection{Specific Data Type Predicates} % 6.2.2.
\edithead {\csdag 36 (p75)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd characterp} {\em object}
\\ \bf with &
\cltxt
{\clkwd characterp} {\em object} \&{\clkwd optional}
{\em repertoire}
\editend
\\
\edithead {\csdag 37 (p75)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd characterp} is true if its argument is a character,
and otherwise is false.
\\ \bf with &
\cltxt
If {\em repertoire} is omitted, {\clkwd characterp}
is true if its argument is a character object,
and otherwise is false.
If a {\em repertoire} argument is specified,
{\clkwd characterp} is true if its argument
is a character object and a member of the specified repertoire,
and
otherwise is false.
For example, {\clkwd (characterp \#$\backslash$A}
{\clkwd :Latin)}
is true since \#$\backslash$A is a member of the
Latin character registry. {\em repertoire} may be any supported
character registry name or the names
{\clkwd :base} or {\clkwd :standard}. {\clkwd (characterp x :base)} is
true if its argument is a member of the base character
repertoire and false
otherwise.
{\clkwd (characterp x :standard)} is
true if its argument is a member of the standard character
subrepertoire and false
otherwise.
\editend
\\
\edithead {\csdag 38 (p75)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd (characterp x) $\equiv$ (typep x \apostrophe character)}
\\ \bf with &
\cltxt
{\clkwd (characterp x :standard) $\equiv$ (typep x \apostrophe
(character :standard)}
\editend
\\
\edithead {\csdag 72 (p76)}
\editstart
\\ \bf replace &
\cltxt
See also {\clkwd standard-char-p, string-char-p, streamp,}
\\ \bf with &
\cltxt
See also {\clkwd standard-char-p, streamp,}
\editend
\setcounter{subsubsection}{2}
\subsubsection{Equality Predicates} % 6.2.3.
\edithead {\csdag 75 (p81)}
\editstart
\\ \bf replace &
\cltxt
which ignores alphabetic case and certain other attributes
of characters;
\\ \bf with &
\cltxt
which ignores alphabetic case
of characters;
\editend
%----------------------------------------------------------------------
\setcounter{section}{6}
\section{Control Structure} % 7
%----------------------------------------------------------------------
\setcounter{subsection}{1}
\subsection{Generalized Variables} % 7.2.
\edithead {\csdag 19 modify table (p95)}
\editstart
\\ \bf replace &
\cltxt
char string-char
\\ &
schar string-char
\\ \bf with &
\cltxt
char character
\\ &
schar character
\editend
\\
\edithead {\csdag 22 table entry (p96)}
\editstart
\\ \bf delete &
\cltxt
char-bit first set-char-bit
\editend
%----------------------------------------------------------------------
\setcounter{section}{9}
\section{Symbols} % 10
%----------------------------------------------------------------------
\edithead {\csdag 3 (p163)}
\editstart
\\ \bf replace &
\cltxt
It is ordinarily not permitted to alter a symbol's print name.
\\ \bf with &
\cltxt
It is an error to alter a symbol's print name.
\editend
\setcounter{subsection}{1}
\subsection{The Print Name} % 10.2.
\edithead {\csdag 5 (p168)}
\editstart
\\ \bf replace &
\cltxt
It is an extremely bad idea
\\ \bf with &
\cltxt
It is an error and an extremely bad idea
\editend
%----------------------------------------------------------------------
\setcounter{section}{10}
\section{Packages} % 11
%----------------------------------------------------------------------
\setcounter{subsection}{6}
\subsection{Package System Functions and Variables} % 11.7.
\edithead {\csdag 31 (p184,intern)}
\editstart
\\ \bf append &
\cltxt
All strings, base and extended, are acceptable {\em string}
arguments.
\editend
%----------------------------------------------------------------------
\setcounter{section}{12}
\section{Characters} % 13
%----------------------------------------------------------------------
\edithead {\csdag 6 after (p233)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd char-code-limit} [{\clkwd Constant}]
\\ &
The value of {\clkwd char-code-limit} is a non-negative integer
that is the upper exclusive bound on values produced by the
function {\clkwd char-code}, which returns the {\em code}
of a given character; that is, the values returned by
{\clkwd char-code} are non-negative and strictly less than
the value of {\clkwd char-code-limit}.
There may be unassigned codes between 0 and
{\clkwd char-code-limit} which
are not legal arguments to {\clkwd code-char}.
\\ &
\cltxt
{\clkwd *all-character-registry-names*} [{\clkwd Variable}]
\\ &
The value of {\clkwd *all-character-registry-names*} is a list of
all character registry names supported by the implementation.
\editend
\setcounter{subsection}{0}
\subsection{Character Attributes} % 13.1.
\edithead {\csdag replace entire section (p233)}
\editstart
\\ \bf with &
\cltxt
Earlier versions of Common LISP incorporated {\em font} and
{\em bits} as attributes of character objects. These are
considered implementation-defined attributes and
if supported by an implementation
effect the action of selected functions. In particular,
the following effects are noted:
\\ &
\begin{itemize}
\item Attributes, such as those
dealing with how the character is displayed or its typography,
are not part of the character code.
For example, bold-face, color
or size are not considered part of the character code.
\item If two characters differ in any attributes,
then they are not {\clkwd char=}.
\item If two characters have identical
attributes, then their ordering by
{\clkwd char}$<$ is consistent with the numerical ordering by the
predicate $<$ on
their code attributes. (Similarly for {\clkwd char}$>$,
{\clkwd char}$>=$ and {\clkwd char}$<=$.)
\item The effect, if any, on {\clkwd char-equal} of each
attribute has to be specified as part of
the definition of that attribute.
\item The effect of {\clkwd char-upcase} and {\clkwd char-downcase}
is to preserve attributes.
\item The function {\clkwd char-int} is equivalent to {\clkwd char-code}
if no attributes are associated with
the character object.
\item The function {\clkwd int-char} is equivalent to {\clkwd code-char}
if no attributes are associated with
the character object.
\item It is implementation dependent whether characters within
double quotes have attributes removed.
\item It is implementation dependent whether
attributes are removed from symbol names by {\clkwd read}.
\end{itemize}
\editend
\setcounter{subsection}{1}
\subsection{Predicates on Characters} % 13.2.
\edithead {\csdag 3 (p234)}
\editstart
\\ \bf replace &
\cltxt
argument is a "standard character" that is, an object of type
{\clkwd standard-char}.
Note that any character with a non-zero {\em bits} or {\em font}
attribute
is non-standard.
\\ \bf with &
\cltxt
argument is one of the Common LISP standard character subrepertoire.
\editend
\\
\edithead {\csdag 4 (p234)}
\editstart
\\ \bf delete &
\cltxt
Note that any character with non-zero ...
\editend
\\
\edithead {\csdag 6 (p235)}
\editstart
\\ \bf replace &
\cltxt
Of the standard characters all but \#$\backslash${\clkwd Newline}
are graphic.
The semi-standard characters \#$\backslash${\clkwd Backspace},
\#$\backslash${\clkwd Tab},
\#$\backslash${\clkwd Rubout},
\#$\backslash${\clkwd Linefeed},
\#$\backslash${\clkwd Return},
and \#$\backslash${\clkwd Page} are not graphic.
\\ \bf with &
\cltxt
Of the standard characters all but \#$\backslash${\clkwd Newline}
are graphic.
\editend
\\
\edithead {\csdag 7 (p235)}
\editstart
\\ \bf delete &
\cltxt
Programs may assume that graphic ...
\editend
\\
\edithead {\csdag 8 (p235)}
\editstart
\\ \bf delete &
\cltxt
Any character with a non-zero bits...
\editend
\\
\edithead {\csdag 9 (p235)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd string-char-p} ...
\editend
\\
\edithead {\csdag 10 (p235)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 13 (p235)}
\editstart
\\ \bf replace &
\cltxt
If a character is alphabetic, then it is perforce graphic. Therefore
any character
with a non-zero bits attribute cannot be alphabetic. Whether a
character is
alphabetic is may depend on its font number.
\\ \bf with &
\cltxt
If a character is alphabetic, then it is perforce graphic.
\editend
\\
\edithead {\csdag 22 (p236)}
\editstart
\\ \bf replace &
\cltxt
If a character is either uppercase or lowercase, it is necessarily
alphabetic (and
therefore is graphic, and therefore has a zero bits attribute).
However, it is permissible in theory for an alphabetic character
to be neither
uppercase nor lowercase (in a non-Roman font, for example).
\\ \bf with &
\cltxt
If a character is either uppercase or lowercase, it is necessarily
alphabetic (and
therefore is graphic).
\editend
\\
\edithead {\csdag 25 (p236)}
\editstart
\\ \bf replace &
\cltxt
The argument {\em char} must be a character object, and {\em radix}
must be a non-negative
integer. If {\em char} is not a digit of the radix specified
\\ \bf with &
\cltxt
The argument {\em char} must be in the standard character
subrepertoire and
{\em radix} must be a non-negative integer.
If {\em char} is not a standard character or is not a digit of the
radix specified
\editend
\\
\edithead {\csdag 51 (p237)}
\editstart
\\ \bf delete &
\cltxt
If two characters have the same bits ...
\editend
\\
\edithead {\csdag 52 (p237)}
\editstart
\\ \bf replace &
\cltxt
If two characters differ in any attribute (code, bits, or font), then
they are different.
\\ \bf with &
\cltxt
If the codes of two characters differ, then
they are different.
\editend
\\
\edithead {\csdag 94 (p239)}
\editstart
\\ \bf replace &
\cltxt
The predicate {\clkwd char-equal} is like {\clkwd char=}, and
similarly for the others, except
according to a different ordering such that differences of bits
attributes and case are ignored, and font information is taken into
account in an implementation dependent manner.
\\ \bf with &
\cltxt
The predicate {\clkwd char-equal} is like {\clkwd char=}, and
similarly for the others, except
according to a different ordering such that differences of case
are ignored.
\editend
\\
\edithead {\csdag 97 example (p239)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char-equal \#$\backslash$A \#$\backslash$Control-A) is true}
\editend
\\
\edithead {\csdag 98 (p239)}
\editstart
\\ \bf delete &
\cltxt
The ordering may depend on the font ...
\editend
\setcounter{subsection}{2}
\subsection{Character Construction and Selection} % 13.3.
\edithead {\csdag 3 (p239)}
\editstart
\\ \bf replace &
\cltxt
The argument {\em char} must be a character object.
{\clkwd char-code} returns the {\em code} attribute of the
character object;
this will be a non-negative integer less than the (normal) value
\\ \bf with &
\cltxt
The argument {\em char} must be a character object.
{\clkwd char-code} returns the {\em code} of the
character object;
this will be a non-negative integer less than the value
\editend
\\
\edithead {\csdag 4 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-bits } ...
\editend
\\
\edithead {\csdag 5 (p240)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 6 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-font } ...
\editend
\\
\edithead {\csdag 7 (p240)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 8 (p240)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd code-char {\em code} \&optional {\em (bits 0) (font 0)}
[{\em Function}]}
\\ \bf with &
\cltxt
{\clkwd code-char {\em code}
[{\em Function}]}
\editend
\\
\edithead {\csdag 9 (p240)}
\editstart
\\ \bf replace &
\cltxt
All three arguments must be non-negative integers. If it is possible
in the
implementation to construct a character object whose code attribute
is {\em code},
whose
bits attribute is {\em bits}, and whose font attribute is {\em font},
then such an object
is returned;
\\ \bf with &
\cltxt
The argument must be a non-negative integer. If it is possible
in the
implementation to construct a character object identified by
{\em code},
then such an object is returned;
\editend
\\
\edithead {\csdag 10 (p240)}
\editstart
\\ \bf replace &
\cltxt
For any integers, {\em c, b,} and {\em f}, if {\clkwd (code-char
{\em c b f})} is
\\ \bf with &
\cltxt
For any integer, {\em c}, if {\clkwd (code-char
{\em c})} is
\editend
\\
\edithead {\csdag 12 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char-bits (code-char } ...
\editend
\\
\edithead {\csdag 13 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char-font (code-char } ...
\editend
\\
\edithead {\csdag 14 (p240)}
\editstart
\\ \bf delete &
\cltxt
If the font and bits attributes ...
\editend
\\
\edithead {\csdag 15 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char= (code-char (char-code ...}
\editend
\\
\edithead {\csdag 16 (p240)}
\editstart
\\ \bf delete &
\cltxt
is true.
\editend
\\
\edithead {\csdag 17 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd make-char} ...
\editend
\\
\edithead {\csdag 18 (p240)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 19 (p240)}
\editstart
\\ \bf delete &
\cltxt
If {\em bits} or {\em font} are zero ...
\editend
\\
\edithead {\csdag 19 (p240)}
\editstart
\\ \bf append &
\cltxt
{\clkwd find-char} {\em label registry} [{\em Function}]
\\ &
{\clkwd find-char} returns a character object.
The arguments {\em label} and {\em registry} are names
(objects coerceable to strings as if by the function {\clkwd string})
of character registries and labels.
{\em label}
uniquely identifies a character within the character
registry named {\em registry}.
If the implementation does not support the specified
character, {\clkwd nil} is returned.
\editend
\setcounter{subsection}{3}
\subsection{Character Conversions} % 13.4.
\edithead {\csdag 8 (p241)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd char-upcase} returns a character object with the same
font and bits attributes as {\em char}, but with possibly a
different code attribute.
\\ \bf with &
\cltxt
{\clkwd char-upcase} returns a character object with possibly
a different code.
\editend
\\
\edithead {\csdag 10 (p241)}
\editstart
\\ \bf replace &
\cltxt
Similarly, {\clkwd char-downcase} returns a character object with the
same font and bits attributes as {\em char}, but with possibly a
different code attribute.
\\ \bf with &
\cltxt
Similarly, {\clkwd char-downcase} returns a character object with
possibly a different code.
\editend
\\
\edithead {\csdag 12 (p241)}
\editstart
\\ \bf delete &
\cltxt
Note that the action of ...
\editend
\\
\edithead {\csdag 13 (p241)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd digit-char {\em weight} \&optional ({\em radix} 10)
({\em font} 0) [{\em Function}]}
\\ \bf with &
\cltxt
{\clkwd digit-char {\em weight} \&optional ({\em radix} 10)
[{\em Function}]}
\editend
\\
\edithead {\csdag 14 (p241)}
\editstart
\\ \bf replace &
\cltxt
All arguments must be integers. {\clkwd digit-char} determines
whether or not it is
possible
to construct a character object whose font attribute is {\em font},
and whose {\em code}
\\ \bf with &
\cltxt
All arguments must be integers. {\clkwd digit-char} determines
whether or not it is
possible to construct a character object whose {\em code}
\editend
\\
\edithead {\csdag 15 (p242)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd digit-char} cannot return {\clkwd nil} if {\em font}
is zero, {\em radix}
\\ \bf with &
\cltxt
{\clkwd digit-char} cannot return {\clkwd nil}.
{\em radix}
\editend
\\
\edithead {\csdag 22 (p242)}
\editstart
\\ \bf delete &
\cltxt
Note that no argument is provided for ...
\editend
\\
\edithead {\csdag 23 through 30 (p242, char-int, int-char)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-int} {\em char}
\editend
\\
\edithead {\csdag 32 (p242)}
\editstart
\\ \bf replace &
\cltxt
All characters that have zero font and bits attributes and that are
non-graphic
\\ \bf with &
\cltxt
All characters that are
non-graphic
\editend
\\
\edithead {\csdag 33 (p243)}
\editstart
\\ \bf replace &
\cltxt
The standard newline and space characters have the respective
names {\clkwd Newline} and {\clkwd Space}. The semi-standard
characters have the names {\clkwd Tab, Page, Rubout, Linefeed,
Return,} and {\clkwd Backspace}.
\\ \bf with &
\cltxt
The standard newline and space characters have the respective
names {\clkwd Newline} and {\clkwd Space}.
\editend
\\
\edithead {\csdag 35 (p243)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-name} will only locate "simple" ...
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd name-char} may accept other names for characters
in addition to those returned by {\clkwd char-name}.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd char-registry-name} {\em char} [{\em Function}]
\\ &
{\clkwd char-registry-name} returns a string representing
the character registry to which {\em char} belongs.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd char-label} {\em char} [{\em Function}]
\\ &
{\clkwd char-label} returns a string representing
the character label of {\em char}.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd char-ccs-value} {\em char name} [{\em Function}]
\\ &
{\clkwd char-ccs-value} returns the non-negative integer
representing the encoding of the character {\em char} in
The coded character set named by {\em name}.
If the implementation does not support the specified
coded character set, {\clkwd nil} is returned. If the
named coded character set does not contain the character,
{\clkwd nil} is returned.
\editend
\setcounter{subsection}{4}
\subsection{Character Control-Bit Functions} % 13.5.
\edithead {\csdag delete entire section (p243)}
\editstart
\editend
%----------------------------------------------------------------------
\setcounter{section}{13}
\section{Sequences} % 14
%----------------------------------------------------------------------
\setcounter{subsection}{0}
\subsection{Simple Sequence Functions} % 14.1
\edithead {\csdag 21 (p249,make-sequence)}
\editstart
\\ \bf append &
\cltxt
If type {\clkwd string} is specified, the result is
equivalent to {\clkwd make-string}.
\editend
%----------------------------------------------------------------------
\setcounter{section}{17}
\section{Strings} % 18
%----------------------------------------------------------------------
\edithead {\csdag 1 (p299)}
\editstart
\\ \bf replace &
\cltxt
Specifically, the type {\clkwd string} is identical to the type
{\clkwd (vector string-char),}
which in turn is the same as {\clkwd (array string-char (*))}.
\\ \bf with &
\cltxt
Specifically, the type {\clkwd string} is a subtype of
{\clkwd vector}
and consists of vectors specialized by subtypes of {\clkwd character}.
\editend
\setcounter{subsection}{0}
\subsection{String Access} % 18.1.
\edithead {\csdag 4 (p300)}
\editstart
\\ \bf replace &
\cltxt
character object. (This character will necessarily satisfy the
predicate
{\clkwd string-char-p}).
\\ \bf with &
\cltxt
character object.
\editend
\\
\edithead {\csdag 9 (p300)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd setf} may be used with {\clkwd char} to destructively
replace a character within a string.
\\ \bf with &
\cltxt
{\clkwd setf} may be used with {\clkwd char} to destructively
replace a character within a string.
The new character must be of a type which can be stored in the
string; it is an error otherwise.
\editend
\setcounter{subsection}{2}
\subsection{String Construction and Manipulation} % 18.3.
\edithead {\csdag 2 (p302)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd make-string {\em size} \&key :initial-element [{\em Function}]}
\\ \bf with &
\cltxt
{\clkwd make-string {\em size} \&key :initial-element :element-type
[{\em Function}]}
\editend
\\
\edithead {\csdag 3 (p302,make-string)}
\editstart
\\ \bf replace &
\cltxt
This returns a string (in fact a simple string) of length {\em size},
each of whose characters has been initialized to the
{\clkwd :initial-element} argument. If an {\clkwd :initial-element}
argument is not specified, then the string will be initialized
in an implementation-dependent way.
\\ \bf with &
\cltxt
This returns a string of length {\em size},
each of whose characters has been initialized to the
{\clkwd :initial-element} argument. If an {\clkwd :initial-element}
argument is not specified, then the string will be initialized
in an implementation-dependent way.
The {\clkwd :element-type} argument names the type of the elements
of the string; a string is constructed of the most specialized
type that can accommodate elements of the given type.
If {\clkwd :element-type} is omitted, the type
{\clkwd character} is the default.
\editend
\\
\edithead {\csdag 5 (p302,make-string)}
\editstart
\\ \bf replace &
\cltxt
A string is really just a one-dimensional array of "string
characters" (that is,
those characters that are members of type {\clkwd string-char}).
More complex character arrays may be constructed using the function
{\clkwd make-array}.
\\ \bf with &
\cltxt
More complex character arrays may be constructed using the function
{\clkwd make-array}.
\editend
\\
\edithead {\csdag 29 (p304,make-string)}
\editstart
\\ \bf replace &
\cltxt
If {\em x} is a string character (a character of type
{\clkwd string-char}), then
\\ \bf with &
\cltxt
If {\em x} is a character, then
\editend
%----------------------------------------------------------------------
\setcounter{section}{21}
\section{Input/Output} % 22
\setcounter{subsection}{0}
\subsection{Printed Representation of LISP Objects} % 22.1.
\setcounter{subsubsection}{0}
\subsubsection{What the Read Function Accepts} % 22.1.1.
\edithead {\csdag Table 22-1: Standard Character Syntax Types (p336)}
\editstart
\\ \bf delete entry &
\cltxt
{\clkwd <tab>} {\em whitespace}
\\ &
{\clkwd <page>} {\em whitespace}
\\ &
{\clkwd <backspace>} {\em constituent}
\\ &
{\clkwd <return>} {\em whitespace}
\\ &
{\clkwd <rubout>} {\em constituent}
\\ &
{\clkwd <linefeed>} {\em whitespace}
\editend
\setcounter{subsubsection}{1}
\subsubsection{Parsing of Numbers and Symbols} % 22.1.2.
\edithead {\csdag Table 22-3: Standard Constituent Character
Attributes (p340)}
\editstart
\\ \bf delete entry &
\cltxt
{\clkwd <backspace>} {\em illegal}
\\ &
{\clkwd <tab>} {\em illegal}
\\ &
{\clkwd <linefeed>} {\em illegal}
\\ &
{\clkwd <page>} {\em illegal}
\\ &
{\clkwd <return>} {\em illegal}
\\ &
{\clkwd <rubout>} {\em illegal}
\editend
\setcounter{subsubsection}{3}
\subsubsection{Standard Dispatching Macro Character Syntax} % 22.1.4.
\edithead {\csdag Table 22-4: Standard \# Macro Character Syntax (p352)}
\editstart
\\ \bf delete entry &
\cltxt
{\clkwd \#<backspace>} {\em signals error}
\\ &
{\clkwd \#<tab>} {\em signals error}
\\ &
{\clkwd \#<linefeed>} {\em signals error}
\\ &
{\clkwd \#<page>} {\em signals error}
\\ &
{\clkwd \#<return>} {\em signals error}
\\ &
{\clkwd \#<rubout>} {\em undefined}
\editend
\\
\edithead {\csdag 8 (p353)}
\editstart
\\ \bf replace &
\cltxt
The following names are standard across all implementations:
\\ \bf with &
\cltxt
All non-graphic
characters, including extended characters, are uniquely
named in an implementation-dependent manner.
In particular, an implementation may support names of the
form {\em label:registry}.
The following names are standard across all implementations:
\editend
\\
\edithead {\csdag 11 through 18 inclusive delete (p353)}
\editstart
\\ \bf delete &
\cltxt
The following names are semi-standard; ...
\editend
\\
\edithead {\csdag 20 through 26 inclusive delete (p354)}
\editstart
\\ \bf delete &
\cltxt
The following convention is used in implementations ...
\editend
\\
\edithead {\csdag 108 (p360)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd \#<space>, \#<tab>, \#<newline>, \#<page>, \#<return>}
\\ \bf with &
\cltxt
{\clkwd \#<space>, \#<newline>}
\editend
\setcounter{subsubsection}{4}
\subsubsection{The Readtable} % 22.1.5.
\edithead {\csdag 3 (p360)}
\editstart
\\ \bf replace &
\cltxt
Even if an implementation supports characters with non-zero
{\em bits} and {\em font}
attributes, it need not (but may) allow for such characters to
have syntax
descriptions
in the readtable. However, every character of type
{\clkwd string-char}
must be represented in the readtable.
\\ \bf with &
\cltxt
All base and extended characters
are representable in the readtable.
\editend
\setcounter{subsubsection}{5}
\subsubsection{What the Print Function Produces} % 22.1.6.
\edithead {\csdag 13 (p366)}
\editstart
\\ \bf replace &
\cltxt
is used. For example, the printed representation of the character
\#$\backslash$A
with control
and meta bits on would be \#$\backslash${\clkwd CONTROL-META-A},
and that of
\#$\backslash$a with control and meta bits on would be
\#$\backslash${\clkwd CONTROL-META-$\backslash$a}.
\\ \bf with &
\cltxt
is used (see 22.1.4).
\editend
\setcounter{subsection}{2}
\subsection{Output Functions} % 22.3.
\setcounter{subsubsection}{0}
\subsubsection{Output to Character Streams} % 22.3.1.
\edithead {\csdag 26 (p384)}
\editstart
\\ \bf replace &
\cltxt
({\em not} the substring delimited by {\clkwd :start} and
{\clkwd :end}).
\\ \bf with &
({\em not} the substring delimited by {\clkwd :start} and
{\clkwd :end}).
Only characters which are members of the coded character set(s)
associated with the output stream or \#$\backslash${\clkwd Newline}
are valid to be written;
it is an error otherwise. All character streams must provide
appropriate line division behavior for
\#$\backslash${\clkwd Newline}.
\editend
\\
\edithead {\csdag 27 after (p384)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd external-coded-string-length} {\em object} \&{\clkwd optional}
{\em output-stream} [{\em Function}]
\\ &
{\clkwd external-coded-string-length}
returns the number of implementation defined
units required for the object on the output-stream. If
not applicable to the output stream, the function
returns {\clkwd nil}.
This number corresponds to the current state of the stream
and may change if there has been intervening output.
If the output stream is not specified {\clkwd *standard-output*}
is the default.
\editend
\setcounter{subsubsection}{2}
\subsubsection{Formatted Output to Character Streams} % 22.3.3.
\edithead {\csdag 23 delete example (p387)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (format nil "Type} $\tilde{ }$
{\clkwd :C to $\tilde{ }$ :A."} . . .
\editend
\\
\edithead {\csdag 66 (p389)}
\editstart
\\ \bf replace &
\cltxt
$\tilde{ }${\clkwd :C} spells out the names of the control bits and
represents non-printing
characters by their names: {\clkwd Control-Meta-F, Control-Return,
Space}.
This is a "pretty" format for printing characters.
\\ \bf with &
\cltxt
$\tilde{ }${\clkwd :C}
represents non-printing
characters by their names: {\clkwd Newline,
Space}. This is a "pretty" format
for printing characters.
\editend
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\setcounter{section}{22}
\section{File System Interface} % 23
\setcounter{subsection}{1}
\subsection{Opening and Closing Files} % 23.2.
\edithead {\csdag 2 (p418)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd open {\em filename} \&key :direction :element-type}
{\clkwd :if-exists :if-does-not-exist}
[{\em Function}]
\\ \bf with &
\cltxt
{\clkwd open {\em filename} \&key :direction :element-type}
{\clkwd
:external-coded-character-format}
{\clkwd :if-exists :if-does-not-exist}
[{\em Function}]
\editend
\\
\edithead {\csdag 11 (p419)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd string-char}
\\ &
The unit of transaction is a string-character. The functions
{\clkwd read-char}
and/or {\clkwd write-char} may be used on the stream.
\\ \bf with &
\cltxt
The default value of {\clkwd :element-type} is
implementation-defined as character or a subtype of character.
\\ &
{\clkwd base-character}
\\ &
The unit of transaction is a base character. The functions
{\clkwd read-char}
and/or {\clkwd write-char} may be used on the stream.
\editend
\\
\edithead {\csdag 16 (p419)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd character}
\\ &
The unit of transaction is any character, not just a string-character.
The functions {\clkwd read-char} and/or {\clkwd write-char} may
be used on the stream.
\\ \bf with &
\cltxt
{\clkwd character}
\\ &
The unit of transaction is any character.
The functions {\clkwd read-char} and/or {\clkwd write-char} may
be used on the stream.
\editend
\\
\edithead {\csdag 19 after (p420)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd :external-coded-character-format}
\\ &
This argument specifies a name or list of
names(s) indicating an implementation recognized scheme for
representing 1 or more coded character sets with non-homogeneous codes.
\\ &
The default value is {\clkwd :default} and is
implementation defined but must include the
base characters.
\\ &
As many coded character set names must be provided as the
implementation requires for that external coding convention.
\\ &
References to standard ISO coded character set names must
include the full ISO reference number and approval year.
The following are valid ISO reference names:
:ISO8859/1-1987, :ISO6937/2-1983, :ISO646-1983, etc..
All implementation recognized schemes are formed from
{\clkwd standard-p} characters.
\editend
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\begin{thebibliography}{wwwwwwww 99}
\bibitem[Ida87]{ida87} M. Ida, et al.,
{\em
JEIDA Common LISP Committee Proposal on Embedding Multi-Byte Characters
},
ANSI X3J13 document 87-022, (1987).
\bibitem[ISO 646]{iso646} ISO,
{\em
Information processing -- ISO 7-bit coded character set
for information interchange
},
ISO (1983).
\bibitem[ISO 4873]{iso4873} ISO,
{\em
Information processing -- ISO 8-bit code for information
interchange -- Structure and rules for implementation
},
ISO (1986).
\bibitem[ISO 6937/1]{iso6937/1} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 1: General introduction
},
ISO (1983).
\bibitem[ISO 6937/2]{iso6937/2} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 2: Latin alphabetic and non-alphabetic
graphic characters
},
ISO (1983).
\bibitem[ISO 8859/1]{iso8859/1} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. 1
},
ISO (1987).
\bibitem[ISO 8859/2]{iso8859/2} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 2: Latin alphabet No. 2
},
ISO (1987).
\bibitem[ISO 8859/6]{iso8859/6} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 6: Latin/Arabic alphabet
},
ISO (1987).
\bibitem[ISO 8859/7]{iso8859/7} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 7: Latin/Greek alphabet
},
ISO (1987).
\bibitem[Kerns87]{kerns87} R. Kerns,
{\em
Extended Characters in Common LISP
},
X3J13 Character Subcommittee document, Symbolics Inc (1987).
\bibitem[Kurokawa88]{kurokawa88} T. Kurokawa, et al.,
{\em
Technical Issues on International Character Set Handling in Lisp
},
ISO/IEC SC22 WG16 document N33, (1988).
\bibitem[Linden87]{linden87} T. Linden,
{\em
Common LISP - Proposed Extensions for International Character Set
Handling
},
Version 01.11.87, IBM Corporation (1987).
\bibitem[Steele84]{steele84} G. Steele Jr.,
{\em
Common LISP: the Language
},
Digital Press (1984).
\bibitem[Xerox87]{xerox87} Xerox,
{\em
Character Code Standard, Xerox System Integration Standard
},
Xerox Corp. (1987).
\end{thebibliography}
\end{document} % End of document.
∂22-Feb-89 1333 Common-Lisp-mailer Jan 1 cs proposal comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:32:43 PST
Date: Wed, 22 Feb 89 02:09:18 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.020918.baggins@almvma>
Subject: Jan 1 cs proposal comments
>> From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
>> Subject: Comments on the Character proposal dated January 1, 1989
>>
>> Page 6 -- *all-registry-names* should be renamed to
>> *all-character-registry-names*; the word "registry" by itself
>> is too general.
I made this change to the latest version of the proposal.
>>
>> Page 9 -- the fourth bullet requires a defined total ordering of all
>> characters. This seems unnecessary, and is impossible to implement in any
>> system (such as Symbolics Genera) that allows dynamic addition of character
>> registries by third-party software vendors and by users; in such a system
>> character codes have to be allocated dynamically and therefore their order
>> cannot be fixed ahead of time.
You are quite right. This bullet is removed.
>>
>> Page 9 -- This says an implementation must define the result of
>> standard-char-p on the characters it supports. I think that is incorrect.
>> Common Lisp fully defines the result of standard-char-p, which is NIL
>> for all characters added by an implementation.
Right. This bullet is removed.
>>
>> Page 14 -- This EXTERNAL-WIDTH function probably should be part of a
>> database facility or a terminal screen template facility; I'm not sure it
>> is useful by itself. Also note that its result is only meaningful with
>> respect to a specific state of the stream. To give two examples, with the
>> SO/SI encoding the answer can vary by 1 depending on whether the stream is
>> already shifted into the correct state for the first character; with the
>> universal encoding Symbolics uses, the answer can vary by a lot depending on
>> whether the character repertoires appearing in the string have been used
>> earlier on the same stream (and hence have been assigned encoding numbers).
>> Because of this dependence on the state of the stream, I cannot think of
>> any correct use of EXTERNAL-WIDTH that does not involve immediately
>> outputting the string to the stream. Therefore I believe the same effect
>> can be achieved without adding any new functions, by calling FILE-POSITION,
>> outputting to the stream, calling FILE-POSITION again, and subtracting. If
>> you still want to propose this feature, you should change the name: use
>> "length" instead of "width", since that's the word Common Lisp always uses,
>> and use a name that relates to the :EXTERNAL-CODE-FORMAT option to OPEN;
>> for example, STRING-LENGTH-IN-EXTERNAL-CODE-FORMAT or
>> EXTERNAL-CODED-STRING-LENGTH.
I changed the name to EXTERNAL-CODED-STRING-LENGTH. The description
already contained a comment regarding current state. Actually, I
favored the STREAM-INFO proposal which was voted down. This is
much less ambitious but I still feel more useful than actually
forcing I/O, backing up and rewriting. It's also not clear
that your alternative has the same effect since it seems that
some unwanted side-effects would occur such as premature appearance
on a display screen.
>>
>> Page 24 -- I can't figure out what you intend the meaning of SIMPLE-STRING
>> to be. Your report mostly does not mention it, but it doesn't say to
>> remove it either. If I have correctly correlated page 24 back to CLtL, you
>> are defining SIMPLE-STRING to be synonymous with SIMPLE-GENERAL-STRING.
>> Maybe what you really meant, though, was what you said in November you
>> would do, which was to make SIMPLE-STRING mean (AND STRING SIMPLE-ARRAY),
>> in other words a union of several subtypes. This is particular confusing
>> because Common Lisp uses the name SIMPLE-VECTOR to mean what you might call
>> a simple general vector, that is, (SIMPLE-ARRAY T 1) rather than
>> (SIMPLE-ARRAY * 1). Here are my suggestions for what to do with the
>> various names for string subtypes:
>>
>> STRING As a union of all strings, this is fine.
>> GENERAL-STRING I think (VECTOR CHARACTER) is just as good.
>> BASE-STRING I think (VECTOR BASE-CHARACTER) is just as good.
>> SIMPLE-STRING Should mean (SIMPLE-ARRAY CHARACTER 1).
>> SIMPLE-BASE-STRING This is fine.
>> SIMPLE-GENERAL-STRING This name is horrible, use SIMPLE-STRING.
>>
>> My rationale for these suggestions largely comes from thinking about
>> which of these names would ever be used in type declarations and about
>> how these names relate to the other names already in Common Lisp. To
>> repeat older comments:
>>
>> Pages 19 and 20 introduce a new type named simple-base-string, in addition
>> to simple-string. If you think about how simple-string would be used for
>> compiler optimization, it makes sense for simple-string to be the name for
>> the single simplest representation, rather than a name for a whole family
>> of representations that would have to be discriminated at run time. Thus
>> what you call simple-base-string should be called simple-string, and what
>> you call simple-string should just be called (simple-array character (*)).
>> This would not be an incompatible change in the meaning of simple-string.
>> Simple-string would be analogous to simple-vector.
>>
>> I changed my mind slightly on that and now claim that while SIMPLE-STRING
>> should still be a single representation, not a union, it should be the
>> representation that can hold all characters. This is both because of the
>> principle that correct programs should be easier to write than
>> extra-efficient programs, and because of the powerful analogy with the name
>> SIMPLE-VECTOR. Then the name SIMPLE-BASE-STRING is also needed for
>> convenient type declarations of the more efficient but less functional
>> string representation. That name is good, by analogy to BASE-CHARACTER.
>>
>> Adopting the above suggestions helps you decide what to do about the
>> SCHAR, SBCHAR, and SGCHAR mess. First of all, you only need two functions,
>> not three, because there are only two specified specialized representations.
>> SCHAR should be for what I've called SIMPLE-STRING, SBCHAR should be
>> for SIMPLE-BASE-STRING, and SGCHAR is not needed. (In fact I would prefer
>> to remove all of the specialized versions of AREF from the language, in
>> favor of THE or type declarations, but I know that would only pass over
>> some peoples' dead bodies so I won't push it.)
>>
>> In case you are wondering, I have no quarrel with the name BASE-CHARACTER
>> and would not want to see it removed. I guess I differ from Larry here,
>> unless I erred when I wrote down his comments during the meeting.
The statement on p24 making SIMPLE-STRING == (SIMPLE-ARRAY CHARACTER (*))
was in error. P25 had it right. Since we changed SCHAR to accept
all simple strings there is no reason for SGCHAR and SBCHAR and
these are eliminated.
String and simple-string are (more clearly I hope) defined as union
types. I've changed the terminology from 'for the purpose of
declaration' to 'for object creation'. Perhaps there is a better
term but the effect seems to be identical to what you suggest. That is,
correct, portable programs are easier to write, one simply uses
string and simple-string. More efficient, less portable programs
need to specify the specialized subtype(s) explicitly.
Having both string and simple-string defined as union types seems
desirable on the basis of uniformity.
Of the type abbreviations I think BASE-CHARACTER is the most
useful and GENERAL-STRING, SIMPLE-BASE-STRING and SIMPLE-GENERAL-STRING
less so. I don't believe that any of these really complicate the
language.
>>
>> Page 25 -- The discussion of STRING and SIMPLE-STRING thinks that there
>> is a distinction between declaration and discrimination, but Common Lisp
>> no longer has such a distinction. Even when Common Lisp did have such
>> a distinction, the meanings for declaration stated here were incorrect.
I changed this to 'object creation'. Perhaps there is a better term.
>>
>> Page 29 -- *all-character-registry-names* has to be a variable, not a
>> constant, to accomodate systems (such as Symbolics Genera) that allows
>> dynamic addition of character registries by third-party software vendors
>> and by users.
Right, I made this change.
>>
>> Page 35 -- CHAR-REGISTRY should be renamed to CHAR-REGISTRY-NAME, so that
>> if at some later time character registry objects are added, there is no
>> possibility of confusion about whether this function returns a name or
>> an object.
Right, I made this change.
>>
>> Page 40 -- the default :ELEMENT-TYPE for OPEN cannot be BASE-CHARACTER. I
>> think this was discussed at the X3J13 meeting. The report suffers from a
>> confusion between two meanings of BASE-CHARACTER: the character type
>> implemented most efficiently by the Lisp, and the character type most
>> natural to the file system. These are not always the same. Furthermore,
>> in a network-based system that supports multiple file systems equally
>> (Symbolics Genera is an example), each file system might have a different
>> natural character type. BASE-CHARACTER should just mean the character type
>> implemented most efficiently by the Lisp. The default for :ELEMENT-TYPE
>> has two viable choices that I can see, and maybe you should just propose
>> both and let people vote:
>>
>> (1) CHARACTER. This matches the behavior of MAKE-STRING and friends,
>> adheres to the principle that writing correct programs should be easier
>> than writing extra-efficient programs (since making a program correct
>> requires making every part of it correct, while making a program
>> efficient only requires improving the bottlenecks), and doesn't cost
>> anything in implementations that don't have extended characters.
>>
>> (2) The most natural type for the particular pathname being opened.
>> In some systems this would be a constant, and in a subset of those
>> systems this would be BASE-CHARACTER, however in general this might
>> depend on the host, device, or even type fields of the pathname,
>> and might also depend on information stored in the file system.
>> In general this would always be an (improper) supertype of
>> BASE-CHARACTER, but it's probably a bad idea to make that a requirement,
>> as some file systems might not be able to implement it conveniently.
>> Again this doesn't cost anything in implementations that don't have
>> extended characters.
The discussion on p16 about the base coded character set efficiency
has been removed. The default element-type now states that it is
implementation defined as character or a subtype of character.
>>
>> The relationship of option 2 to :ELEMENT-TYPE :DEFAULT (a feature that
>> already exists in Common Lisp) needs to be clarified. Perhaps they
>> are the same.
The same? I don't understand. For example, I can imagine the
element-type default as base-character and the external format
defaulted to either an ASCII or EBCDIC encoding.
>>
>> Also the following promise from 14 November did not show up in the report:
>>
>> >> There should be a name for the "natural" encoding and there should be a
>> >> specification of the properties of the natural encoding that a programmer
>> >> can rely on. Suggestions for the name include :BASE, :NATURAL, and
>> >> :INTERCHANGE. The definition probably involves the concept of data
>> >> interchange with non-Lisp programs on the same system.
>>
>> This will be added to the revision.
I lied. No one came up with the 'properties' of such an encoding.
Do you have some text to suggest?
>>
>> Appendix B -- I disagree with the way you've used deprecation. I'll
>> comment on each individual point:
>> - I see no justification for deprecating STANDARD-CHAR.
>> - I agree that STRING-CHAR should be deprecated, not deleted nor kept.
>> - I think fonts and bits should be removed outright, not deprecated,
>> because no portable program could possibly be using them.
>> - I think the CHAR-INT function needs to be kept, although the INT-CHAR
>> function should go away. This is for hashing. See comments below
>> on character attributes.
I've removed Appendix B and mention of deprecation. STANDARD-CHAR
is simply (characterp :standard). String-char is back in as
implementation-defined either character or base-character (and
maybe should be voted as a deprecated type).
>>
>> No particular page -- the use of strings for naming registries, labelling
>> characters, and naming external code formats is objectionable. Nothing
>> else in Common Lisp is named by strings. Use of strings might lead to
>> efficiency problems. We feel that keyword symbols are the appropriate
>> objects to use for these three kinds of names.
I changed these back to symbols.
>>
>> No particular page -- We agree with the deprecation or deletion of the two
>> particular character attributes defined by CLtL, but not with the
>> deprecation of the whole concept of character attributes. In fact on page
>> 20 you say "characters are uniquely distinguished by their codes," which
>> makes it impossible to have character attributes at all. The language must
>> define how conforming programs should be written so that they will work
>> both in implementations with character attributes and in implementations
>> without them. For example, the value of (eql x (code-char (char-code x)))
>> is unspecified. Another thing that needs to be said is that the exact
>> character operations (char=, string=, etc.) respect all character
>> attributes, while the inexact character operations (char-equal,
>> string-equal, etc.) respect or ignore each character attribute in an
>> implementation-defined but consistent fashion. Some of what you say on
>> page 44 about attributes in general needs to be part of the spec, not
>> deprecated. I would retain everything on that page except for INT-CHAR and
>> the last bullet (referring to bits and fonts), and I would add a remark
>> that FIND-SYMBOL and INTERN respect character attributes. If you want,
>> perhaps I or someone else at Symbolics can provide exact text for what
>> to say about character attributes that you could insert into your report.
I moved the attribute list previously in Appendix B back into the
description of characters. Let me know what text you would like
to see for FIND-SYMBOL and INTERN and I'll add it to the list.
>> No particular page -- On the subject of defining character registries in a
>> separate document, and relating them to ISO standards for character
>> encoding: I think that's fine. I don't see anything wrong with introducing
>> the concept of character registry and the requirement that each character
>> object relates to exactly one registry. However, I think the somewhat
>> random list of character registries on pages 7-8 and again on page 21 does
>> not belong in the language specification. Even the names of the
Right. They are not part of the Common LISP standard. The revised
document is considerably clearer in this regards.
>> standardized character registries belong in the character registry
>> standard, not in the Common Lisp language standard. I'm confused about the
>> meaning of BASE, STANDARD, and CONTROL as character registry names; these
>> are mentioned in your report but not explained very well. If these are
>> character registries that are required to exist in all Common Lisp
>> implementations, then unlike the others they do belong in the Common Lisp
>> language standard, not in the character registry standard.
By CONTROL, I meant a registry which contains the various control
codes mentioned in the various ISO coded character set standards.
BASE and STANDARD are no longer mentioned here. They are allowed
as Common LISP repertiore names in characterp and the character
type specifier.
>>
>> At the meeting there was some discussion about the issue of enumerating all
>> characters in a character registry. People claimed incorrectly that it was
>> impossible. In fact it's possible to do this, with questionable
>> efficiency, by the following program:
>>
>> (dotimes (code char-code-limit)
>> (let ((char (code-char code)))
>> (when char
>> (when (eq (char-registry-name char) desired-registry-name)
>> ... process this char ...))))
>>
>> Of course you have to change the EQ to EQUALP if you continue to use
>> strings to name character registries. For more efficiency, you could add
>> a way to iterate over all the codes in one character registry, but I think
>> that is unnecessary.
>>
>>
>> TYPOS:
Right. I've made these corrections.
>>
>> 25 -- base-string is missing from the Table 4-1 amendment.
>>
>> 26 -- general-string is not an array of BASE characters, also the first
>> two paragraphs under A.4.8 are garbled (the two separate sentences for
>> strings for symbols got smushed together).
>>
>> 37 -- This says the default for the :ELEMENT-TYPE option to MAKE-STRING
>> is SIMPLE-STRING. Actually it's CHARACTER.
>>
∂22-Feb-89 1334 Common-Lisp-mailer cs proposal comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:33:35 PST
Date: Wed, 22 Feb 89 03:48:56 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.034856.baggins@almvma>
Subject: cs proposal comments
>> From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
>> Subject: comments on character proposal
>>
>> Getting rid of bits and fonts (section 2.1) seems like a very good
>> idea to me. I would argue for deleting these "features" completely
>> instead of merely deprecating them, because there now seems to be
>> general agreement that the whole idea was brain-damaged in the first
>> place, plus it's just about impossible to use them portably anyway
>> (since implementations are free not to support them). Deprecating the
>> features would simply perpetuate the current sad state of affairs in
>> to the ANSI standard.
I deleted Appendix B from the proposal. The attribute check list is
incorporated into the character chapter as implementation dependent.
>>
>> I am not at all sure why we need to standardize the idea of character
>> registries at all, much less state that a character can only belong to
>> one registry, or define a standard set of registries. What does having
>> registries buy the user, other than perhaps a way to test whether a
>> character belongs to one or not? Why isn't it sufficient just to say
>> that implementations can support extended characters, and leave it at
>> that?
The registries are introduced to allow an application a portable
way to name, compose and decompose characters. Currently, there is
no way to do this in any programming language. There are other
possiblities. For example, simply labeling all characters
uniquely; another to define a universal coded character set and use
these numeric codes to 'name' characters. I don't think using
numbers for naming characters is useful since I'll always forget
what character 34539 actually is! Registries seem to provide a
framework for useful categorization of characters. It also
avoids the current mess that the coded character set standards
are in.
>>
>> I'm confused about how you propose to handle characters that appear in
>> more than one character repetoire, and whether characters with accent
>> marks are considered distinct from characters without accents. For
>> example, is the French "C" with a cedilla distinct from a normal
>> French "C", and is that distinct from the standard-char "C"?
We handle characters that appear in more than one repertoire by
using registries. No character appears in more than one registry.
The constituents of the registries are not defined by Common LISP.
I believe that in most environments today, it is recognized that
characters with accents are distinct from their vanilla cousins.
As we have proposed registries, they contain semantically
distinct characters.
>>
>> The way the document describes things now, it seems like the Common
>> Lisp standard would have to include a statement of exactly what
>> characters belong in each of the standard registries listed in section
>> 2.2. Otherwise, implementors might go off and define their own
>> character registries that happen to include some characters that ought
>> to belong in one of these standard registries. For instance, the machine
>> I happen to be sitting in front of right now supports an 8-bit native
>> character set, and it seems perfectly reasonable for a Lisp runnning on
>> this machine to include all 256 characters in its base character set,
>> but some of those might actually be supposed to live off in some other
>> registry.
The registries are independent of any coded character sets.
In particular, coded character sets are not registries. Your base
repertoire (set of 256 characters) are possibly drawn from
several registries.
You are correct that lacking an international standard (or ANSI one),
for character registries an implementation could define the
a single registry containing all supported characters. It could
also define NO registries and use only the conventional naming
of characters. I expect an implementation taking the no-cost way
would choose the second approach. On the other hand, an
implementation supporting text processing across international
boundaries is more likely to define some reasonable registries
eg. Latin, Greek, etc..
>>
>> Also in section 2.2, why is it necessary for there to be a total
>> ordering, or even a partial ordering, of all characters? It seems
>> like CHAR< and friends are not very useful except when comparing base
>> characters anyway. It seems like it would difficult to get things
>> like the Spanish N-with-twiddle character to collate correctly anyway,
>> given the constraints you have put on how character codes are derived
>> and the requirement that CHAR< be just like < on the char-codes.
Right. This is now removed.
>>
>> It doesn't seem like STANDARD-CHAR-P belongs in the list of character
>> predicates on p. 9, since no extended characters can possibly be
>> STANDARD-CHAR-P anyway.
Right. This is now removed.
>>
>> The stuff in section 2.3 seems mostly reasonable to me. It's not really
>> clear why you need GENERAL-STRING (as distinct from STRING) and
>> SIMPLE-GENERAL-STRING (as distinct from SIMPLE-STRING). Again, some
>> rationale would be helpful.
GENERAL-STRING means (VECTOR CHARACTER). This is not the meaning of
STRING (a union type). I agree that GENERAL-STRING is not much
of an abbreviation over (VECTOR CHARACTER). It still seems somewhat
more mnemonic.
>>
>> In section 2.4, the general idea of specifying an external character
>> encoding to OPEN seems reasonable. However, I'm confused by the
>> business about having more than one coded character set mixed
>> together. If a character appears in more than one coded character
>> set, which encoding takes precedence? It seems like this has not been
>> well thought-out. Also, seeing as though we have just voted down a
>> proposal to add an EXTERNAL-WIDTH function, it seems like a very bad
>> idea to lump it in here.
Some encoding schemes allow disjoint coded characters sets to
coexist. That is, a given character would appear on one but not
the other. For example, a ISO8859/1 coded character set could
coexist with a coded character set for Chinese.
As for External-width, it was part of our subcommittee discussions
long before the recent stream proposal. It will be a separate
item in the list of character votes.
>>
>> Now for the general comments.
>>
>> One thing that is not clear to me from reading this document is how
>> much of it has already been standardized by ISO. I share Larry's
>> concern that we might standardize one thing, and then have ISO go off
>> and standardize something completely different. I think it's a
>> mistake to try to second-guess what ISO might do.
The revision might make this clearer. I think this is a
red herring anyhow. As a programming language committee
we need to specify what is useful in the context of LISP. We
can't expect a coded character set committee to figure it out.
On the other hand, we can influence what gets standardized
by defining our framework. The ISO Prolog std committee is
interested in what we define.
>>
>> I am also concerned about trying standardize things that have not yet
>> been implemented. I think it's a mistake to try to do language design
>> in a standards committee.
>>
>> Finally, I have some problems with the presentation of your proposal.
>> One problem, as I mentioned at the meeting, is that you've made it an
>> all-or-nothing package, and I can't vote for the whole thing because
>> there are some parts of it that do not seem appropriate, even though I
>> would support some of the other changes individually. The other
>> problem is that Appendix A is virtually unreadable. Some of the
>> conceptual changes involve wording changes to several passages, and I
>> know that there are some other changes in the appendix that are not
>> mentioned in the introductory blurb at all. Is it totally impossible
>> to recast the changes in standard cleanup format proposals? The
>> advantage of that format is that it presents more context, including a
>> clear statement of why the existing CLtL behavior is "broken" and a
>> rationale for the proposed change.
There will be several votes regarding this proposal. I don't
intend to rewrite the document in a cleanup format.
>>
>> I know that we adopted things like the CLOS document that were
>> presented as single mega-proposals, but those were primarily additions
>> to the language and what you are proposing is essentially a large
>> number of incompatible changes. I'm having a hard time identifying
>> what all of those changes are.
>>
Actually, I don't think it's as large a number of changes as you
imply. In any case, the vote split should help this out.
∂22-Feb-89 1334 Common-Lisp-mailer cs proposal comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:34:09 PST
Date: Wed, 22 Feb 89 04:51:15 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
cc: David Gray <GRAY%DSG.CSC.TI.COM@RELAY.CS.NET>
Message-ID: <890222.045115.baggins@almvma>
Subject: cs proposal comments
>> From: David N Gray <Gray@DSG.csc.ti.com>
>> Subject: characters proposal
>>
>> I have read the documented titled "Extensions to Common LISP to Support
>> International Character Sets" dated January 1, 1989, and feel that it is
>> not much of an improvement over what we saw in October. Following are
>> some random comments about things I happened to notice; this is not
>> intended to be a comprehensive analysis.
>>
>> First, documents such as this ought to be labelled with an X3J13
>> document number so that they can be referred to conveniently and
>> unambiguously.
>>
>> "Appendix A" and "Appendix B" really should be chapters 3 and 4 since
>> they are an essential part of the proposal, rather than being an
>> appendage to it.
Appendix B is now eliminated. Appendix A is really quite unlike
chapters 1 and 2 in structure.
>>
>> Page 7 says that the definition of semi-standard-characters "is replaced
>> by a more uniform approach with introduction of the Control Character
>> Registry". Do you really mean that it _will_be_ replaced when the
>> Control Character Registry is defined in some subsequent document? I
>> certainly don't see anything in this document that could be considered a
>> replacement.
Yes. The revision is clearer on this. This document does not define
names for character registries nor their constituents.
>>
>> This whole concept of registries seems rather strange. Is the intent
>> that the alphabetic characters of the standard characters are to be in
>> the "Latin" registry while characters such as period and comma are in
>> "Latin-Punctuation"? Is #\NEWLINE in the "Control" registry? Where do
>> the digits go -- "Mathematical"?. Is #\- a "Latin-Punctuation" or a
>> "Mathematical"? Which registry is #\SPACE in? Now tell me what to do
>> with the extra non-Latin alphabetic characters used in Sweedish? Does
>> that require a separate registry for just those additional characters?
>> Now we have simple text in a single language using characters from at
>> least four different registries. Do you really think it possible to
>> agree on a "fixed", non-extensible, set of "Mathematical" or "Pattern"
>> characters?
Actually, I believe the simplicity of the registry framework will make
agreement easy. Currently, members of the coded character set
committees spend vast amounts of time lobbying for inclusion of their
favorite character(s) in the 'popular' coded character set standard.
The effect of not being included means fewer installations will
support their native language properly.
I think a new group, hopefully formed within
programming languages, should define the registries rather than
the existing coded character set committees. There is no competition
between registries, ie. no advantage of one over another. What this
committee has to agree upon is 1) a useful set of registry names and
2) definition of the constituents of each registry. The only argument
I would anticipate is "are the semantics of my alpha the same
or different from your alpha" type debates.
By the way,
the registries are fixed only in that a Common LISP implementation
cannot modify the standard definitions. This guarantees an application
program can portably rely on the composition and decomposition
functions to establish the availability of any given character.
>>
>> Page 9 says that an implementation needs to specify the total ordering
>> of characters within each registry, but what about the ordering of
>> characters in different registries? Is that completely undefined?
There is no ordering of characters within registries. As mentioned
in Hawaii, the character index (a number) was changed to character
label (a symbol) throughout the proposal.
>>
>> Page 25 section A.4.5 doesn't specify the syntax of a registry name; did
>> you intend it to be a string?
These have been changed to be symbols.
>>
>> Page 27 has an example using (typep x '(character "standard")) but
>> page 25 said that had to be a registry name; "standard" is not a
>> registry name.
The revision is clearer on this. character and characterp can take
registry names, :base or :standard. The meaning of :base and :standard
is defined by Common LISP as the base character repertoire and
standard character repertoire respectively.
>>
>> Page 29 - *ALL-REGISTER-NAMES* -- a list of strings?
Now a list of symbols.
>>
>> Page 33 -- FIND-CHAR -- does the index value within a registry have any
>> portable meaning? Is that intended to be specified for the standard
>> registries? Is "base" supposed to be accepted here? If not, how can
>> you access the base codes? If I were going to construct a character
>> from its index value, it would be more meaningful to use an index
>> relative to some coded character set rather than these registries.
FIND-CHAR takes a character label and registry. These are specified
by the registry standard. Base is not a registry name. We have
introduced a new function CHAR-CCS-VALUE which takes a character
object and a coded character set name (a symbol) and returns the
encoding of the character in the coded character set.
>>
>> Page 36, the last sentence doesn't make sense. The default for
>> :ELEMENT-TYPE would have to be either CHARACTER or BASE-CHARACTER.
Right. I've made this change.
>>
>> Page 37, section A.22.1.1 -- the part being deleted specifies the
>> meaning of including tab and form-feed characters in a Common Lisp
>> source file; do you really intend that to not have any standard meaning?
>> If my editor uses tabs for indenting, does that mean that the resulting
>> source file is not a standard-conforming program?
That really depends on the definition of a conforming program. Is
this defined yet?
>>
>> Page 38, the first reference to p360 of CLtL should be p353; the
>> deletion here says that there shall not be any standard name for the
>> commonly used control characters such as tab and form-feed. That still
>> seems wrong to me.
>>
>> Page 41, what's the point of appending "ccs" to the name of the
>> standard? Presumably that stands for "coded character set", but isn't
>> that adequately implied by the fact that this string will follow the
>> keyword :EXTERNAL-CODE-FORMAT ? The use of "default" seems odd since
>> :DEFAULT is used everywhere else.
This was to distinguish from someone referring to the set of characters
(repertoire) represented in a given coded character set. Ie. to
distinguish ISO8859/6-1987 coded character set from the ISO8850/6-1987
repertoire. In fact, the ISO coded character set standards never
refer to repertoires in isolation (ie. without the codes), so I've
dropped the 'ccs'. Also, "default" is now :DEFAULT as elsewhere.
>>
>> I agree with Moon that the excising of bits and fonts has not been done
>> carefully enough for them to be compatible extensions.
>>
I think the new revision takes care of this by incorporating the
attribute list as part of the language proper (ie. not deprecated).
∂27-Feb-89 0140 Common-Lisp-mailer pluralization: two proposals
Received: from DST.BOLTZ.CS.CMU.EDU ([128.2.220.61]) by SAIL.Stanford.EDU with TCP; 27 Feb 89 01:39:51 PST
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 27 Feb 89 04:37:12 EST
To: common-lisp@sail.stanford.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: pluralization: two proposals
Date: Mon, 27 Feb 89 04:37:06 EST
Message-ID: <3127.604575426@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU
The ~P format directive and its : and @ variants provide only the suffixes
"s" and "ies". What about nouns whose singular forms end in "s" or
"z"? They use "es" to form their plural, e.g.
bus --> buses
glass --> glasses
buzz --> buzzes
First, I propose that ~P and ~:P be modified to produce the "es" plural
form instead of "s" when given a numeric argument of -1.
Second, a more ambitious proposal: how about introducing a new conditional
directive to handle arbitrary singular/plural distinctions:
~:@[ singular ~; plural ~]
If the argument is EQL to 1, the first alternative is taken; otherwise the
second alternative is taken. This lets you do neat things like:
(format nil "There ~:@[is~;are~]~:* ~D~:* ~:@[wolf~;wolves~] here." 3)
==> "There are 3 wolves here."
(format nil "There ~:@[is~;are~]~:* ~D~:* ~:@[wolf~;wolves~] here." 1)
==> "There is 1 wolf here."
(format nil "Your tab comes to ~D~:* ~:@[wolfs'~;wolves'~] head~:P." -5)
==> "Your tab comes to -5 wolves' heads."
(format nil "Your tab comes to ~D~:* ~:@[wolf's~;wolves'~] head~:P." 1)
==> "Your tab comes to 1 wolf's head."
Notes:
1) The example with -5 shows why special plural forms can't simply be
handled with an ordinary conditional by writing
~[plural~;singular~:;plural~]
2) The pluralization conditional is also useful for handling things like
possessive forms (wolf's vs. wolves') and the verb "be" (is vs. are).
-- Dave
∂01-Mar-89 1218 Common-Lisp-mailer Why do input functions need RECURSIVE-P argument?
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:18:14 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 1 Mar 89 15:14:26 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 1 Mar 89 15:12:30 EST
Date: Wed, 1 Mar 89 15:15 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Why do input functions need RECURSIVE-P argument?
To: common-lisp@sail.stanford.edu
Message-Id: <19890301201524.9.BARMAR@OCCAM.THINK.COM>
Something has been bothering me for a while, and I was reminded about it
when reading the latest version of the draft chapter on I/O for ANSI CL:
why is the RECURSIVE-P argument necessary for Common Lisp input
functions?
I understand that it is necessary for an input function to know whether
it is a top-level call or a recursive call, but that doesn't tell me why
this must be an argument to the functions. The implementation could
simply make use of a flag in the stream object, e.g.
(defstruct stream
...
(inside-input-function-p nil)
...)
(defun read (&optional stream ...)
...
(let ((recursive-p (stream-inside-input-function-p stream)))
(unwind-protect
(progn
(setf (stream-inside-input-function-p stream) t)
...)
(setf (stream-inside-input-function-p stream) recursive-p)))
...)
The only justification for making it an argument would be to allow calls
that actually are recursive to pretend that they aren't; however, I
can't think of a legitimate reason to want to do this. And this
provides an easy trap for read-macro programmers to fall into, when they
accidentally forget to include the RECURSIVE-P argument.
MacLisp didn't have a RECURSIVE-P argument and it worked OK in this
regard, didn't it?
barmar
∂01-Mar-89 1934 Common-Lisp-mailer Why do input functions need RECURSIVE-P argument?
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 1 Mar 89 19:32:23 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 276814; Wed 1-Mar-89 22:26:31 EST
Date: Wed, 1 Mar 89 22:26 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Why do input functions need RECURSIVE-P argument?
To: barmar@Think.COM, common-lisp@sail.stanford.edu
In-Reply-To: <19890301201524.9.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890302032621.6.GSB@GANG-GANG.SCRC.Symbolics.COM>
Date: Wed, 1 Mar 89 15:15 EST
From: Barry Margolin <barmar@Think.COM>
Something has been bothering me for a while, and I was reminded about it
when reading the latest version of the draft chapter on I/O for ANSI CL:
why is the RECURSIVE-P argument necessary for Common Lisp input
functions?
I understand that it is necessary for an input function to know whether
it is a top-level call or a recursive call, but that doesn't tell me why
this must be an argument to the functions. The implementation could
simply make use of a flag in the stream object, e.g.
(defstruct stream
...
(inside-input-function-p nil)
...)
(defun read (&optional stream ...)
...
(let ((recursive-p (stream-inside-input-function-p stream)))
(unwind-protect
(progn
(setf (stream-inside-input-function-p stream) t)
...)
(setf (stream-inside-input-function-p stream) recursive-p)))
...)
The only justification for making it an argument would be to allow calls
that actually are recursive to pretend that they aren't; however, I
can't think of a legitimate reason to want to do this. And this
provides an easy trap for read-macro programmers to fall into, when they
accidentally forget to include the RECURSIVE-P argument.
This won't work right on an interactive stream (*terminal-io*) when a
new toplevel call to read can be initiated while within the dynamic
scope of that unwind-protect body.
It is true, however, that the same sort of stream encapsulation
technology which can be used to handle sophisticated printing (to get
around the lack of a recursive-p argument to the printing functions!)
could be used by the reader. That is, recursive calls to read don't get
the original stream argument, but some other stream which encapsulates
other state of the read in progress.
MacLisp didn't have a RECURSIVE-P argument and it worked OK in this
regard, didn't it?
No. Maclisp went to lots of effort to reset state on when stacking
anything (error, interrupts, etc.). i.e., global knowledge about the
state of the reader (and other things) was needed.
barmar
∂02-Mar-89 1512 Common-Lisp-mailer
Received: from NMFECC.ARPA by SAIL.Stanford.EDU with TCP; 2 Mar 89 15:11:08 PST
Received: from tuva.sainet.mfenet by ccc.mfenet with Tell via MfeNet ;
Thu, 2 Mar 89 15:06:40 PST
Date: Thu, 2 Mar 89 15:06:40 PST
From: POTHIERS%TUVA.SAINET.MFENET@NMFECC.ARPA
Message-Id: <890302150640.23200215@NMFECC.ARPA>
To: COMMON-LISP@SAIL.STANFORD.EDU
Subject: LOOP macro
Date: Thu, 2-MAR-1989 16:07 MST
X-VMS-Mail-To: @CL
I'm looking for a LOOP macro. Is it going to be in the new CL standard?
If it is going to be in the standard, can someone tell me what the
standard says about it?
Unfortunately, I'm not sure what type of loop macro I'm looking for!
I'm porting some code that is supposed to be CL except for the LOOP.
It looks similar to the Symbolics LOOP. I know they at least use
COLLECT, FOR, DO and probably lots more.
If anyone can send be a relatively complete LOOP I can wing it from
there.
Please send replies directly to me at
pothiers%tuva.sainet@nmfecc.arpa
Thank Yew!
∂09-Mar-89 1246 Common-Lisp-mailer Loop
Received: from cheops.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 9 Mar 89 12:43:02 PST
Received: by cheops.cis.ohio-state.edu (5.59/2.890120)
id AA04131; Thu, 9 Mar 89 15:40:50 EST
Date: Thu, 9 Mar 89 15:40:50 EST
From: Arun Welch <welch@cis.ohio-state.edu>
Message-Id: <8903092040.AA04131@cheops.cis.ohio-state.edu>
To: common-lisp@sail.stanford.edu
Subject: Loop
Can someone out there point me to documentation for/a description of the
recently-passed LOOP macro? Portable code would be nice, too.
Converting between Interlisp Clisp forms and CL DO is really twisting
my brain...:-)
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@tut.cis.ohio-state.edu
∂10-Mar-89 0734 Common-Lisp-mailer re: [LOOP docs and source]
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 10 Mar 89 07:34:36 PST
Received: from cousteau.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
id AA00200; Fri, 10 Mar 89 10:35:09 est
Message-Id: <2814536088-2521485@Cousteau>
Sender: DAVID%Cousteau@cs.umass.edu
Date: Fri, 10 Mar 89 10:34:48 EST
From: Forster%vax2@cs.umass.edu
To: common-lisp@sail.stanford.edu
Cc: welch@cis.ohio-state.EDU
Subject: re: [LOOP docs and source]
> From: Arun Welch <welch@cis.ohio-state.EDU>
>
> Can someone out there point me to documentation for/a description of the
> recently-passed LOOP macro? Portable code would be nice, too.
In September of 1987, and later on New Year's in 1988, two loop macros were
advertised in this netnews group, one the actual distribution, and the other
indicating the ftp address. I'm including editted versions of the original
messages at the end of this message.
I don't know if these correspond to the proposal (apparently from Lucid?)
100%, but they're a start, I guess, and pretty much PD, I gather. As far as
documentation goes, perhaps the originators could forward the proposal
presented to the committee to this list?
- David Forster
________________ KCL stuff: ________________
From: Taiichi Yuasa
<yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>
Here is my code for LOOP, which will be included in the next release of
KCL available from University of Texas.
-- Taiichi
...
;; (c) Copyright Taiichi Yuasa and Masami Hagiya, 1984. All rights reserved.
;; Copying of this file is authorized to users who have executed the true and
;; proper "License Agreement for Kyoto Common LISP" with SIGLISP.
;;;; loop.lsp
;;;;
;;;; defines the sophisticated LOOP macro, with the hope it's
;;;; compatible with Symbolics Common Lisp.
________________ sloop stuff: ________________
From: Bill Schelter <wfs@rascal.ics.utexas.EDU>
... sloop.lisp ... is available on rascal:/usr2/ftp/pub/sloop.lisp
Internet Address:
128.83.144.1 rascal.ics.utexas.edu rascal # sun unix
login anonymous with password guest.
...
Any bug reports or complaints (or even contented user reports)
should also go to that address.
Bill Schelter
________________ End of forwarded text ________________
∂10-Mar-89 0744 Common-Lisp-mailer [LOOP docs and source]
Received: from cheops.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 10 Mar 89 07:44:54 PST
Received: by cheops.cis.ohio-state.edu (5.59/2.890120)
id AA07623; Fri, 10 Mar 89 10:41:58 EST
Date: Fri, 10 Mar 89 10:41:58 EST
From: Arun Welch <welch@cis.ohio-state.edu>
Message-Id: <8903101541.AA07623@cheops.cis.ohio-state.edu>
To: Forster%vax2@cs.umass.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Forster%vax2@cs.umass.edu's message of Fri, 10 Mar 89 10:34:48 EST <2814536088-2521485@Cousteau>
Subject: [LOOP docs and source]
Thanks.
...arun
∂22-Mar-89 0919 Common-Lisp-mailer Common Lisp function signatures
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89 09:19:10 PST
Posted-Date: Wed, 22 Mar 89 09:18:16 PST
Message-Id: <8903221718.AA01878@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
id AA01878; Wed, 22 Mar 89 09:18:26 PST
To: common-lisp@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: Common Lisp function signatures
Date: Wed, 22 Mar 89 09:18:16 PST
Sender: goldman@vaxa.isi.edu
Does anyone out there have a machine processable file containing a
representation of the input-output type signatures of the functions of
CommonLisp? i.e., something that would let me define a function
IO-SIGNATURE, where
IO-SIGNATURE[CONS] ==> (T T) , (CONS)
IO-SIGNATURE[VALUES-LIST] ==> (CONS), (&REST T)
IO-SIGNATURE[+] ==> (NUMBER &rest NUMBER), (NUMBER)
etc.
I would also be interested in other abstract characterizations of
the common lisp functions, such as whether they are "applicative"
or "context dependent".
neil
∂24-Mar-89 1245 Common-Lisp-mailer email address change -- "cvaxa" -> "cogs"
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 24 Mar 89 12:45:27 PST
Received: from syma.sussex.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05669; 24 Mar 89 20:33 GMT
Received: from csuna.cogs.susx.ac.uk (csuna-gateway) by uk.ac.sussex.syma; Fri, 24 Mar 89 20:38:57 GMT
From: Aaron Sloman <aarons%cogs.sussex.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Fri, 24 Mar 89 20:33:20 GMT
Message-Id: <18371.8903242033@csuna.cogs.susx.ac.uk>
To: various_colleagues%cogs.sussex.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: email address change -- "cvaxa" -> "cogs"
In case nobody else has told you, or you need reminding: Please change
all reference in University of Sussex email addresses from "cvaxa" to "cogs".
Cvaxa refers to a machine that dies this month. "cogs" comes via the new
Sequent Symmetry in our computing centre, known as "uk.ac.sussex.syma".
"cogs" is registered as a subdomain of this.
[Apologies if you have received this information more than once.]
Aaron
-----------------------------------------------------------------------
Aaron Sloman,
School of Cognitive and Computing Sciences,
Univ of Sussex, Brighton, BN1 9QN, England
ARPANET : aarons%uk.ac.sussex.cogs@nss.cs.ucl.ac.uk
aarons%uk.ac.sussex.cogs%nss.cs.ucl.ac.uk@relay.cs.net
JANET aarons@cogs.sussex.ac.uk
BITNET: aarons%uk.ac.sussex.cogs@uk.ac
or aarons%uk.ac.sussex.cogs%ukacrl.bitnet@cunyvm.cuny.edu
UUCP: ...mcvax!ukc!cogs!aarons
or aarons@cogs.uucp
IN CASE OF DIFFICULTY use "syma" instead of "cogs"
∂14-Apr-89 2343 Common-Lisp-mailer the "N" in "NCONC"
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Apr 89 23:43:53 PDT
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 15 Apr 89 02:43:45 EDT
To: common-lisp@sail.stanford.edu
cc: jmc@sail.stanford.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: the "N" in "NCONC"
Date: Sat, 15 Apr 89 02:43:43 EDT
Message-ID: <2558.608625823@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU
To complete the 2nd edition of my Lisp book, I am researching the origin of
the "N" convention for naming destructive functions.
>From the description of NCONC in the Lisp 1.5 Programmer's Manual (p. 62),
it seems plausible that the "N" originally stood for "No copy". The manual
never says this explicitly, though.
If any of you Lisp historians out there can shed more light on this
important matter, I'd be much obliged.
-- Dave
∂17-Apr-89 1032 Common-Lisp-mailer the "N" in "NCONC"
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Apr 89 10:32:49 PDT
Received: from INRIA.INRIA.FR by argus.Stanford.EDU with TCP; Mon, 17 Apr 89 10:21:34 PDT
Received: by inria.inria.fr (5.61+/89.0.7) via Fnet-EUnet id AA14241; Mon, 17 Apr 89 09:33:56 +0200 (MET)
Date: Mon, 17 Apr 89 09:30:16 +0200
Received: by ilog.ilog.fr, Mon, 17 Apr 89 09:30:16 +0200
From: padget@ilog.ilog.fr (Julian Padget)
Message-Id: <8904170730.AA08639@ilog.ilog.fr>
To: Dave.Touretzky@CS.CMU.EDU
Cc: common-lisp@sail.stanford.edu, jmc@sail.stanford.edu
In-Reply-To: Dave.Touretzky@b.gp.cs.cmu.edu's message of Sat, 15 Apr 89 02:43:43 EDT <2558.608625823@DST.BOLTZ.CS.CMU.EDU>
Subject: the "N" in "NCONC"
I remember this being discussed on an old lisp mailing list about 5
years ago. KMP (I think) avowed that it was a result of a
misunderstanding which arose as follows: there was a function CONC
which destructively joined two lists together (once upon a time) and
then it was generalised into an N-ary function and renamed NCONC.
Someone else (no names remembered or given) reading the description
decided that the N prefix distinguished it as a destructive operation
and so christened destructive reverse NREVERSE, and so on.
--Julian.
∂17-Apr-89 1120 Common-Lisp-mailer the "N" in "NCONC"
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 17 Apr 89 11:20:37 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 578392; Mon 17-Apr-89 14:20:32 EDT
Date: Mon, 17 Apr 89 14:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: the "N" in "NCONC"
To: padget@ilog.ilog.fr
cc: Dave.Touretzky@CS.CMU.EDU, common-lisp@sail.stanford.edu,
jmc@sail.stanford.edu
In-Reply-To: <8904170730.AA08639@ilog.ilog.fr>
Message-ID: <890417141925.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Mon, 17 Apr 89 09:30:16 +0200
From: padget@ilog.ilog.fr (Julian Padget)
I remember this being discussed on an old lisp mailing list about 5
years ago. KMP (I think) avowed that it was a result of a
misunderstanding which arose as follows: there was a function CONC
which destructively joined two lists together (once upon a time) and
then it was generalised into an N-ary function and renamed NCONC.
Someone else (no names remembered or given) reading the description
decided that the N prefix distinguished it as a destructive operation
and so christened destructive reverse NREVERSE, and so on.
Yes, you probably heard this from me but I got the story (I think) from
Drew McDermott. When I heard it, I raced to my Lisp 1.5 manual to check
it out, and sure enough it doesn't align. I still tell the story,
though, usually disclaiming it as having come from Drew and observing it
to be `probably apocryphal' just because it's so typical of things that
really -do- happen.
∂17-Apr-89 1245 Common-Lisp-mailer Re: the "N" in "NCONC"
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Apr 89 12:45:35 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09161; 17 Apr 89 20:30 BST
Date: Mon, 17 Apr 89 20:22:42 BST
Message-Id: <15142.8904171922@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: the "N" in "NCONC"
To: Julian Padget <padget%ilog.ilog.fr@NSS.Cs.Ucl.AC.UK>,
Dave.Touretzky@cs.cmu.edu
In-Reply-To: Julian Padget's message of Mon, 17 Apr 89 09:30:16 +0200
Cc: common-lisp@sail.stanford.edu, jmc@sail.stanford.edu
> I remember this being discussed on an old lisp mailing list about 5
> years ago. KMP (I think) avowed that it was a result of a
> misunderstanding which arose as follows: there was a function CONC
> which destructively joined two lists together (once upon a time) and
> then it was generalised into an N-ary function and renamed NCONC.
> Someone else (no names remembered or given) reading the description
> decided that the N prefix distinguished it as a destructive operation
> and so christened destructive reverse NREVERSE, and so on.
I've long thought that this story was correct, but if you look at the
Lisp 1.5 manual you'll see that CONC is the n-arg version, NCONC is a
2-arg function, and both work without copying.
-- Jeff
∂17-Apr-89 1319 Common-Lisp-mailer the "N" in "NCONC"
To: common-lisp@SAIL.Stanford.EDU
CC: JMC@SAIL.Stanford.EDU, padget@ILOG.ILOG.FR
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I believe the term comes from ``Non-consing CONCatenate,'' which predates
Maclisp. Possbly Greenblatt, Gosper, or even Mike Levin came up with it.
The InterLisp equivalent is D- as in ``dreverse.''
-rpg-
∂17-Apr-89 1429 Common-Lisp-mailer Re: the "N" in "NCONC"
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 17 Apr 89 14:27:16 PDT
Date: Mon, 17 Apr 1989 17:19-EDT
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
To: common-lisp@SAIL.Stanford.EDU
Subject: Re: the "N" in "NCONC"
> I believe the term comes from ``Non-consing CONCatenate,'' which predates
> Maclisp. Possbly Greenblatt, Gosper, or even Mike Levin came up with it.
> The InterLisp equivalent is D- as in ``dreverse.''
Does that mean that "Dedit" is a non-consing editor? :-)
∂17-Apr-89 1434 Common-Lisp-mailer Re: the "N" in "NCONC"
Received: from gremlin.nrtc.northrop.com by SAIL.Stanford.EDU with TCP; 17 Apr 89 14:34:38 PDT
Received: from tribble by gremlin.nrtc.northrop.com id aa03485;
17 Apr 89 14:31 PDT
To: Dick Gabriel <RPG@sail.stanford.edu>
cc: common-lisp@sail.stanford.edu, JMC@sail.stanford.edu,
padget@ilog.ilog.fr, jbarnett@gremlin.nrtc.northrop.com
Subject: Re: the "N" in "NCONC"
In-reply-to: Your message of 17 Apr 89 13:19:00 -0700.
<1UPwyf@SAIL.Stanford.EDU>
Date: Mon, 17 Apr 89 14:30:56 -0700
From: jbarnett@gremlin.nrtc.northrop.com
The name, "NCONC" was in existence long before InterLisp was ever thought
about. It appeared in the Q32 LISP 1.5 and I think in the MAC Lisp on the
7094 and PDP 10. I'm sure from my own experience that it was in vogue by
the early 1960's. The N in NCONC may be like the D in DREVERSE, but both
NCONC and DREVERSE were in the same systems. In any event, what is more
curious to me than the fact that the name NCONC starts with an N, is the
fact that the function was never and is not called DAPPEND or even NAPPEND.
∂18-Apr-89 0231 Common-Lisp-mailer the "N" in "NCONC"
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Apr 89 02:31:29 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate.lucid.com id AA09534g; Tue, 18 Apr 89 02:31:09 PDT
Received: by bhopal id AA03330g; Tue, 18 Apr 89 02:31:03 PDT
Date: Tue, 18 Apr 89 02:31:03 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904180931.AA03330@bhopal>
To: padget@ilog.ilog.fr
Cc: Dave.Touretzky@CS.CMU.EDU, common-lisp@sail.stanford.edu,
jmc@sail.stanford.edu
In-Reply-To: Julian Padget's message of Mon, 17 Apr 89 09:30:16 +0200 <8904170730.AA08639@ilog.ilog.fr>
Subject: the "N" in "NCONC"
re: . . . KMP (I think) avowed that it was a result of a
misunderstanding which arose as follows: there was a function CONC
which destructively joined two lists together (once upon a time) and
then it was generalised into an N-ary function and renamed NCONC.
This explanation doesn't seem very likely to me. The Lisp 1.5 Programmer's
Manual -- which dates to mid 1962 -- shows both CONC and NCONC as being
N-ary operations.
When I first showed up around MIT in the late 60's, the common gossip
was that the "N" stood for "Non-Consing". Interlisp (nee, BBN-Lisp)
had another nomenclature -- a prefix "D" meant "Destructive" rather
than "Non-Consing". Interestingly, there was one exception to the
Interlisp scheme -- NCONC. Possibly, then, it was trying to remain
compatible with Lisp 1.5. But the pattern must have been instituted
after the break in communications between the BBN gang and the MIT
gang, since MacLisp's predecessor on the PDP6 had NREVERSE whereas
Interlisp has DREVERSE.
In the early days of 7094 Lisp (on CTSS), consing "too much" could
be disastrous. People were known even back then to try tricks to
avoid it. Despite the humongous increase in address space that the
7094 afforded over the 650, there was still the likelihood that all
of the nearly 32 thousand cells would be occupied. And the first
garbage collectors were known to "take a while".
Hmmmm, 32 thousand "new cells"; hmmm, we've come a long way, baby.
-- JonL --
∂19-Apr-89 0857 Common-Lisp-mailer questions about EVALHOOK
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Apr 89 08:56:57 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA13751; Wed, 19 Apr 89 09:57:00 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA07006; Wed, 19 Apr 89 09:56:57 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904191556.AA07006@defun.utah.edu>
Date: Wed, 19 Apr 89 09:56:56 MDT
Subject: questions about EVALHOOK
To: common-lisp@sail.stanford.edu
I have some questions about how EVALHOOK is supposed to work in
implementations whose evaluators compile (or partially compile) forms
passed to EVAL. Page 321 of CLtL says that this technique "renders
the EVALHOOK mechanism relatively useless". Does this mean it's
possible that the *EVALHOOK* function might never be called by EVAL?
Or, might the form argument it receives be some kind of structure
representing the source code, instead of the Lisp source code itself?
Also, page 323 says that "the STEP facility is implemented using this
hook". Is this really a *requirement* on the implementation of STEP,
or just a suggestion on how it *might* be implemented?
-Sandra
-------
∂19-Apr-89 1344 Common-Lisp-mailer intent of (THE <type> <expression>)
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 19 Apr 89 13:44:06 PDT
Posted-Date: Wed, 19 Apr 89 12:44:00 PST
Message-Id: <8904192044.AA21853@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
id AA21853; Wed, 19 Apr 89 13:44:07 -0700
To: common-lisp@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: intent of (THE <type> <expression>)
Date: Wed, 19 Apr 89 12:44:00 PST
Sender: goldman@vaxa.isi.edu
1) Is program P1 a correct common lisp program, or is it "an error":
P1: (let ((x 0))
(declare (integer x))
(setf x (truncate 7 3)))
If P1 is correct, how about P2
P2: (let ((x 0))
(declare (integer x))
(setf x (the integer (truncate 7 3))))
Why this is a question: TRUNCATE returns 2 values. Is (THE INTEGER <EXP>)
equivalent to (THE (VALUES INTEGER &rest T) <EXP>)) -- in which case P2 is
correct, and (THE INTEGER (TRUNCATE 7 3)) returns 2 values, 2 and 1?
Or is (THE INTEGER <EXP>) equivalent to
(THE (VALUES INTEGER &REST T) (VALUES <EXP>))
in which case P2 is correct and (THE INTEGER (TRUNCATE 7 3)) returns a single
value, 2?
Observations: If P1 is correct, and P2 is "an error", then the
"transformation" of wrapping (the <type-specifier> <expression>) around
expressions being assignmened to a variable for which a type has been
declared is NOT a correct transformation in Common Lisp.
Of course if BOTH P1 and P2 are incorrect, it may still be a legitimate
transformation.
Empirical observation that raised this question:
Symbolics' implementation signals an error for P2 (interpreted, though NOT
compiled). It does not signal an error for P1 in any case. This is
consistent with considering P2 to be "is an error" and considering P1 to
be either correct OR "is an error". I don't know what their position is.
I am not able to determine a stance on this question from the text on
pp 161-162 of CLtL84.
Personal preference: I would like (the <type-spec> <exp>), where
<type-spec> was not a VALUES type specifier, to mean
(the <type-spec> (VALUES <exp>))
(the (values integer) (values 1 2)) would be an error.
(the integer (values 0 3)) would be correct and return only one value, 0.
(the (values integer integer) (values 1 2)) would be correct and return 2
values, 1 and 2.
Remotely related question -- can DEFTYPE be used to define VALUES style
or FUNCTION style type specifiers, or only the kind that TYPEP is willing
to accept? On my symbolics implementation, I can do
(deftype two-integers () (values integer integer))
without any error. The interpreter accepts
(the (values integer integer) (values 1 2))
returning two values, 1 and 2.
but the interpreter signals an error for
(the (two-integers) (values 1 2))
which is consistent with considering it to be an error for a use of a
type "macro" defined with DEFTYPE to produce a VALUES style type specifier.
(although the error message scarcely makes that appear to be the offense.)
Neil
∂19-Apr-89 1432 Common-Lisp-mailer intent of (THE <type> <expression>)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 14:32:23 PDT
Return-Path: <mincy@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 19 Apr 89 17:32:24 EDT
Received: from ZENO.THINK.COM by sauron.think.com; Wed, 19 Apr 89 17:31:33 EDT
Date: Wed, 19 Apr 89 17:31 EDT
From: Jeff Mincy <mincy@Think.COM>
Subject: intent of (THE <type> <expression>)
To: goldman@vaxa.isi.edu, common-lisp@sail.stanford.edu
In-Reply-To: <8904192044.AA21853@vaxa.isi.edu>
Message-Id: <19890419213156.5.MINCY@ZENO.THINK.COM>
Date: Wed, 19 Apr 89 12:44:00 PST
From: goldman@vaxa.isi.edu
If P1 is correct, how about P2
P2: (let ((x 0))
(declare (integer x))
(setf x (the integer (truncate 7 3))))
Personal preference: I would like (the <type-spec> <exp>), where
<type-spec> was not a VALUES type specifier, to mean
(the <type-spec> (VALUES <exp>))
(the integer (values 0 3)) would be correct and return only one value, 0.
Neil
(Correct) type declarations are not supposed to affect
the semantics of a correct program. Your type declaration
just changed the the semantics.
(setq x (the integer (truncate 7 3))) should not signal an error.
After all, only one value is being used, and I want to declare
that one value. When giving a non values type declaration such
as INTEGER, it should be taken to declare the first value. Any
other values returned are not declared. If I want to declare
that something returns exactly one value, and it is an integer,
then I can use the type (values integer).
The types INTEGER and (VALUES INTEGER) should either be
equivalent or not, and this should be specified better
in CLtL. I think is it more useful if they are not equivalent.
-jeff
∂19-Apr-89 1522 Common-Lisp-mailer intent of (THE <type> <expression>)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 15:21:49 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Wed, 19 Apr 89 18:17:14 EDT
Date: Wed, 19 Apr 89 18:16 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: intent of (THE <type> <expression>)
To: Jeff Mincy <mincy@Think.COM>
Cc: goldman@vaxa.isi.edu, common-lisp@sail.stanford.edu
In-Reply-To: <19890419213156.5.MINCY@ZENO.THINK.COM>
Message-Id: <19890419221642.8.BARMAR@OCCAM.THINK.COM>
Date: Wed, 19 Apr 89 17:31 EDT
From: Jeff Mincy <mincy@Think.COM>
Date: Wed, 19 Apr 89 12:44:00 PST
From: goldman@vaxa.isi.edu
If P1 is correct, how about P2
P2: (let ((x 0))
(declare (integer x))
(setf x (the integer (truncate 7 3))))
Personal preference: I would like (the <type-spec> <exp>), where
<type-spec> was not a VALUES type specifier, to mean
(the <type-spec> (VALUES <exp>))
(the integer (values 0 3)) would be correct and return only one value, 0.
Neil
(Correct) type declarations are not supposed to affect
the semantics of a correct program. Your type declaration
just changed the the semantics.
The operative word is "correct". If the expression returns two values
and the type declaration is interpreted as specifying that it returns
exactly one value, then the type declaration isn't correct. If this is
the correct interpretation of non-VALUES type specifiers in THE forms,
then the above is just as incorrect as (the float 0).
I'm not sure what the right interpretation of this is. As far as I can
tell, it hasn't come up in X3J13 (there's only one Cleanup issue related
to THE, and it's about a different problem). In the description of the
THE special form, the only wording I can find that indicates either way
is the comments in the examples on p.162. When describing the
interpretation of (the integer (+ x 3)) the comments say "the result of
+ will be an integer." The use of the singular in these comments
implies that the declaration specifies that + will only return one
value.
However, the description of THE as used with SETF, p.96, implies the
other way. It says that
(setf (the <type> <place>) <value>)
is processed as if it were
(setf <place> (the <type> <value>))
Therefore, (setf (the integer x) (truncate 7 3)) would be treated as
(setf x (the integer (truncate 7 3))). Intuitively, the original
version seems correct, so the transformed version should be valid. It
is certainly counterintuitive to require one to write
(setf (the (values integer integer) x)
(truncate 7 3))
This latter problem could be fixed either by fixing the definition of
the THE special form, or by fixing the definition of the THE SETF-place.
barmar
∂20-Apr-89 0741 Common-Lisp-mailer Re: the "N" in "NCONC"
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Apr 89 07:41:39 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08443; 20 Apr 89 15:31 BST
Date: Thu, 20 Apr 89 15:25:29 BST
Message-Id: <20806.8904201425@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: the "N" in "NCONC"
To: Jon L White <@sail.stanford.edu:jonl@lucid.com>,
padget%ilog.ilog.fr@NSS.Cs.Ucl.AC.UK
In-Reply-To: Jon L White's message of Tue, 18 Apr 89 02:31:03 PDT
Cc: Dave.Touretzky@cs.cmu.edu, common-lisp@sail.stanford.edu,
jmc@sail.stanford.edu
> This explanation doesn't seem very likely to me. The Lisp 1.5 Programmer's
> Manual -- which dates to mid 1962 -- shows both CONC and NCONC as being
> N-ary operations.
Um, JonL, when I look in the Lisp 1.5 manual, I see NCONC (p 62)
described as a 2-argument function. CONC is n-argument, Both are
destructive.
∂20-Apr-89 0809 Common-Lisp-mailer Re: the "N" in "NCONC"
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Apr 89 07:41:39 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08443; 20 Apr 89 15:31 BST
Date: Thu, 20 Apr 89 15:25:29 BST
Message-Id: <20806.8904201425@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: the "N" in "NCONC"
To: Jon L White <@sail.stanford.edu:jonl@lucid.com>,
padget%ilog.ilog.fr@NSS.Cs.Ucl.AC.UK
In-Reply-To: Jon L White's message of Tue, 18 Apr 89 02:31:03 PDT
Cc: Dave.Touretzky@cs.cmu.edu, common-lisp@sail.stanford.edu,
jmc@sail.stanford.edu
> This explanation doesn't seem very likely to me. The Lisp 1.5 Programmer's
> Manual -- which dates to mid 1962 -- shows both CONC and NCONC as being
> N-ary operations.
Um, JonL, when I look in the Lisp 1.5 manual, I see NCONC (p 62)
described as a 2-argument function. CONC is n-argument, Both are
destructive.
∂20-Apr-89 0936 Common-Lisp-mailer Re: the "N" in "NCONC"
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Apr 89 09:36:31 PDT
Received: from Riesling.ms by ArpaGateway.ms ; 20 APR 89 06:02:17 PDT
Sender: "Larry_Masinter.PARC"@Xerox.COM
Date: 19 Apr 89 09:36:38 PDT (Wednesday)
Subject: Re: the "N" in "NCONC"
From: masinter.PARC@Xerox.COM
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: padget@ilog.ilog.fr, Dave.Touretzky@CS.CMU.EDU,
common-lisp@sail.stanford.EDU, jmc@sail.stanford.EDU
In-Reply-to: KMP%STONY-BROOK.SCRC.Symbolics:COM's message of Monday, April
17, 1989 11:49 am
Reply-to: masinter.PARC@Xerox.COM
Message-ID: <890420-060217-3764@Xerox>
The convention wasn't universal. While Interlisp had NCONC, it used
DREVERSE (for Destructive REVERSE) , DREMOVE, DSUBST, etc.
∂20-Apr-89 1036 Common-Lisp-mailer re: intent of (THE <type> <expression>)
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 20 Apr 89 10:35:54 PDT
Posted-Date: Thu, 20 Apr 89 09:35:50 PST
Message-Id: <8904201735.AA13354@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
id AA13354; Thu, 20 Apr 89 10:35:53 -0700
To: common-lisp@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: re: intent of (THE <type> <expression>)
Cc: barmar@think.com, mincy@think.com
Date: Thu, 20 Apr 89 09:35:50 PST
Sender: goldman@vaxa.isi.edu
Jeff is absolutely correct in rejecting the resolution I stated as
my preference. It would have said that:
a) (truncate 7 3) is a correct program, and it returns two values
b) (the integer (truncate 7 3)) is a correct program, and it returns one value
But all that has happened (syntactically) is the addition of a type
declaration to a correct program.
I still think the meaning of (the <type-specifier> <expression>) needs
clarification.
What do you think of this alternative:
1) if the <type-specifier> is not of the form (VALUES ...),
then let (VALUES <type-specifier> &rest T) be the effective type specifier.
Otherwise, <type-specifier> itself is the effective type specifier.
2) The value(s) returned by expression must be compatible with the
effective type specifer, where compatibility is as described on page 48
in the definition of VALUES style type specifiers. [But that paragraph
should be expanded to include &allow-other-keys. It should also make
explicit that
i) the value-type list is a lambda list in which type-specifiers
appear where parameter names would appear in a normal lambda list
ii) none the the component type specifiers may be a VALUES type specifier
iii) the type specifiers all appear as top-level components of the value-type
list for positional values (required or &optional),
and as (<symbol> type-specifier) for keyword type-specifiers
(I presume that was the intent?) The <symbol>
is NOT coerced to the keyword package. For example,
(the (values integer &optional number
&key (a symbol) (:b cons) &allow-other-keys)
(values 7 8 :b '(x 1) 'a 3 'b 2))
would be correct.
(the integer (truncate 7 3) would be correct, because it is treated as
(the (values integer &rest t) (integer 7 3)
(the (values integer) (truncate 7 3)) would be an error.
Neil
∂20-Apr-89 1302 Common-Lisp-mailer Re: intent of (THE <type> <expression>)
Received: from cayuga.cs.rochester.edu by SAIL.Stanford.EDU with TCP; 20 Apr 89 13:02:40 PDT
Received: from lesath.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/l) id AA18246; Thu, 20 Apr 89 16:02:25 EDT
Received: from loopback by lesath.cs.rochester.edu (3.2/l) id AA02490; Thu, 20 Apr 89 16:02:14 EDT
Message-Id: <8904202002.AA02490@lesath.cs.rochester.edu>
To: common-lisp@sail.stanford.edu
Subject: Re: intent of (THE <type> <expression>)
In-Reply-To: Your message of Thu, 20 Apr 89 09:35:50 -0800.
<8904201735.AA13354@vaxa.isi.edu>
Date: Thu, 20 Apr 89 16:02:10 -0400
From: quiroz@cs.rochester.edu
Summary: Don't disturb Unaware Callers. Don't let THE pass
back values that it didn't check. [For details, search down for
the string PROPOSAL.]
After the latest note by Neil Goldman, I think I see with less
sympathy the proposed transformations to clarify THE. I suggest
that a guiding concern be this: Unaware Callers don't suffer
unintended weirdness when they call a Multiple Value function.
By Unaware Callers I mean those that don not intentionally use any
of the forms that do something with multiple values.
So, I would have it this way:
(setf x (truncate 7 3)) ; the second value is discarded, right?
(setf x (the integer (truncate 7 3))) ; the second value is also discarded
(setf (the integer x) (truncate 7 3))
would all do the same thing: discard the second value, even for type
checking. I didn't request the second value, I don't want to have
to declare its type. (Also, instead of truncate, think of a user
defined function that over time gets extended to return multiple
values, I don't want this benign extension to break anything that
worked before).
PROPOSAL:
What it boils down to, is that THE should check only as many types
as requested (and pass back only as many). This entails rewording
the entry for THE in p. 138 of CLtL:
* If the type specifier specifier of the THE form is not of the form
(VALUES ...), only one value is checked and passed back. Else, only
as many returned values as specified in the (VALUES ...) specifier
are checked and passed back. (Missing values are assumed to be nil,
they are checked and passed back.) A type specifier of the form
(VALUES ... &rest T) is used to indicate that extra values may be
present, and are not type checked, but are passed back.
Possible draw-back:
(multiple-value-bind (foo bar) (the integer (truncate 7 3))
(declare (type integer foo bar))
(list foo bar))
would be in error (bar would be nil). The program without the THE
declaration looks correct to me, but the declaration screws it up.
That's is philosophically OK with me (Aware Callers have all the
responsibility to do the right thing; only Unaware Callers are
protected from peculiarities of the Multiple Value system), but
still some may feel it to be a touch rude. The fix, of course,
would be:
(multiple-value-bind (foo bar) (the (values integer integer)
(truncate 7 3))
...)
So adding a corect declaration is still possible.
Sorry this got too long.
Cesar
∂20-Apr-89 1404 Common-Lisp-mailer intent of (THE <type> <expression>)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Apr 89 14:04:41 PDT
Received: from fafnir.think.com by Think.COM; Thu, 20 Apr 89 17:04:38 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 20 Apr 89 17:03:41 EDT
Received: from joplin.think.com by verdi.think.com; Thu, 20 Apr 89 16:59:42 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Thu, 20 Apr 89 16:59:15 EDT
Date: Thu, 20 Apr 89 16:59:15 EDT
Message-Id: <8904202059.AA00383@joplin.think.com>
To: quiroz@cs.rochester.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: quiroz@cs.rochester.edu's message of Thu, 20 Apr 89 16:02:10 -0400 <8904202002.AA02490@lesath.cs.rochester.edu>
Subject: intent of (THE <type> <expression>)
...
PROPOSAL:
What it boils down to, is that THE should check only as many types
as requested (and pass back only as many).
No, this is not cool. THE is supposed to act purely as a declaration,
but you are changing it to require it to pass on only as many values
as the type specifer indicates. This could change the semantics of
a suitably devious program.
Better to say that it checks as many types as requsted, but passes on
exactly the values it receives.
--Guy
∂20-Apr-89 1434 Common-Lisp-mailer Re: intent of (THE <type> <expression>)
Received: from cayuga.cs.rochester.edu by SAIL.Stanford.EDU with TCP; 20 Apr 89 14:34:43 PDT
Received: from lesath.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/l) id AA18692; Thu, 20 Apr 89 17:34:34 EDT
Received: from loopback by lesath.cs.rochester.edu (3.2/l) id AA02604; Thu, 20 Apr 89 17:34:28 EDT
Message-Id: <8904202134.AA02604@lesath.cs.rochester.edu>
To: Guy Steele <gls@Think.COM>
Cc: common-lisp@sail.stanford.edu
Subject: Re: intent of (THE <type> <expression>)
In-Reply-To: Your message of Thu, 20 Apr 89 16:59:15 -0400.
<8904202059.AA00383@joplin.think.com>
Date: Thu, 20 Apr 89 17:34:24 -0400
From: quiroz@cs.rochester.edu
| Better to say that it checks as many types as requsted, but passes on
| exactly the values it receives.
That sounds better, indeed. So, do both of Neil's programs remain
correct then? (Meaning here: "(setf x (the integer (truncate 7 3)))"
is as correct as "(setf x (truncate 7 3))")
Cesar
∂02-Jun-89 1725 X3J13-mailer New submission address for LASC
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Jun 89 17:25:43 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA01255g; Fri, 2 Jun 89 16:28:47 PDT
Received: by challenger id AA01058g; Fri, 2 Jun 89 16:26:32 PDT
Date: Fri, 2 Jun 89 16:26:32 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8906022326.AA01058@challenger>
To: common-lisp@sail.stanford.edu, x3j13@sail.stanford.edu
Subject: New submission address for LASC
LISP AND SYMBOLIC COMPUTATION Journal questions and submissions should be
sent to the following new address:
Jan Zubkoff
Associate Editor, LASC
Lucid, Inc.
Route 5, Box 2834
Crawfordville, FL 32327
904/926-8039
Please send 5 copies of your paper for review. The final copy should be
submitted in electronic LaTex form, either by netmail or on a 1.2M floppy.
Volume 2 Issue 2 has just been mailed and Issue 3/4 will be another double
issue due to be mailed in about a month.
There have been some changes I thought you'd like to know about.
Guy L. Steele Jr. has taken a one year sabatical to devote his time to other
pressing activities. Carolyn Talcott has graciously stepped in as Acting
Editor-in-Chief and has made short work of every paper.
Mark Wegman and L. Peter Deutsch have both resigned to devote their time to
research.
Bob Kessler and JonL White have joined our Editorial Board and have given a
great deal of their time reviewing papers.
I'd like to thank each member of our Editorial Board for making this journal
possible.
Richard P. Gabriel Carolyn Talcott
Daniel G. Bobrow Kenneth Kahn
Robert S. Cartwright Robert Kessler
Jerome Chailloux John McCarthy
Daniel P. Friedman Larry Masinter
Martin L. Griss Julian Padget
Paul Hudak David S. Touretzky
Masayuki Ida Mitchell Wand
Gilles Kahn John L. White
Thank you to all the authors who have submitted their work to LASC and have
made this an exceptional joural.
---jan---
∂06-Jul-89 0923 Common-Lisp-mailer CL flyer
Received: from cayuga.cs.rochester.edu ([192.5.53.209]) by SAIL.Stanford.EDU with TCP; 6 Jul 89 09:22:57 PDT
Received: from sol.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/m) id AA29685; Thu, 6 Jul 89 12:21:34 EDT
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (3.2/m) id AA06471; Thu, 6 Jul 89 12:22:17 EDT
Received: from QUCDN.QueensU.CA by cayuga.cs.rochester.edu (5.59/m) id AA29677; Thu, 6 Jul 89 12:20:17 EDT
Received: from qusuno.qucis.queensu.ca by QUCDN.QueensU.CA (IBM VM SMTP R1.2) with TCP; Thu, 06 Jul 89 12:20:55 EDT
Received: by qusuno.qucis.queensu.ca (3.2/SMI-3.2)
id AA00289; Thu, 6 Jul 89 12:22:36 EDT
Date: Thu, 6 Jul 89 12:22:36 EDT
From: tomek@qucis.queensu.ca
Message-Id: <8907061622.AA00289@qusuno.qucis.queensu.ca>
To: cl@cs.rochester.edu
Subject: CL flyer
Dear James,
I have just noticed the CL flyer that has been distributed at ACL meeting
in Vancouver, and I am somewhat baffled. It says that the number 3 of volume
15 (to appear in September) will contain a paper "Non-Singular Concepts
in Natural Language Discourse" by Nick Cercone. Well, Nick is the second of the
TWO authors of this paper, i.e., it is Tomek Strzalkowski and Nick Cercone.
My name may be difficult to spell but that's no reason to drop the first
author's name altogether! Just hoping my name will appear on top of the paper.
Greetings,
Tomek Strzalkowski
∂10-Jul-89 1449 Common-Lisp-mailer SYMBOL-MACROLET
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 10 Jul 89 14:49:08 PDT
Posted-Date: Mon, 10 Jul 89 13:49:20 PST
Message-Id: <8907102149.AA27155@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
id AA27155; Mon, 10 Jul 89 14:49:23 -0700
To: common-lisp@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: SYMBOL-MACROLET
Date: Mon, 10 Jul 89 13:49:20 PST
Sender: goldman@vaxa.isi.edu
Is it the case that the expansion code for a symbol-macro, (unlike a lexical
macro introduced with MACROLET) has not means to obtain the current
lexical environment?
neil
∂10-Jul-89 1534 Common-Lisp-mailer SYMBOL-MACROLET
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Jul 89 15:34:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 623054; 10 Jul 89 18:05:48 EDT
Date: Mon, 10 Jul 89 18:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROLET
To: goldman@vaxa.isi.edu
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8907102149.AA27155@vaxa.isi.edu>
Message-ID: <19890710220541.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 10 Jul 89 13:49:20 PST
From: goldman@vaxa.isi.edu
Is it the case that the expansion code for a symbol-macro, (unlike a lexical
macro introduced with MACROLET) has not means to obtain the current
lexical environment?
There is no expansion code for a symbol-macro. A symbol-macro always
expands into the same thing; one specifies the expansion directly,
rather than specifying Lisp forms that will compute and return the
expansion. Of course a symbol macro could expand into a call to a
regular macro, which could then expand into whatever it wants, potentially
looking at the lexical environment.
∂17-Jul-89 1714 Common-Lisp-mailer exit extent (formerly nonlocal exit from unwind-protect)
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 17 Jul 89 17:14:32 PDT
Posted-Date: Mon, 17 Jul 89 17:14:29 PDT
Message-Id: <8907180014.AA03478@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
id AA03478; Mon, 17 Jul 89 17:14:31 -0700
To: common-lisp@sail.stanford.edu
Subject: exit extent (formerly nonlocal exit from unwind-protect)
Date: Mon, 17 Jul 89 17:14:29 PDT
From: Don Cohen <donc@vaxa.isi.edu>
Is there any way known under the "minimal" proposal to write
an un-exitable loop? Of course, whether that's a good thing
to be able to do is another question.
A more reasonable thing would be to generate an error in the
unwind-protect that would warn the user about exiting and give
him a restart option. However it's not clear to me that even
this is possible under the minimal proposal. Opinions?
∂18-Jul-89 0744 Common-Lisp-mailer sun commonlisp 3.0.2 and in-package
Received: from nprdc.navy.mil by SAIL.Stanford.EDU with TCP; 18 Jul 89 07:44:33 PDT
Received: from atlantic.nprdc.navy.mil by nprdc.navy.mil (5.59/SMI-4.0)
id AA18194; Tue, 18 Jul 89 07:44:02 PDT
Received: by atlantic.nprdc.navy.mil (4.0/SMI-4.0)
id AA20259; Tue, 18 Jul 89 07:44:48 PDT
From: stanonik@nprdc.navy.mil (Ron Stanonik)
Message-Id: <8907181444.AA20259@atlantic.nprdc.navy.mil>
Date: 18 July 1989 0744-PDT (Tuesday)
To: common-lisp@sail.stanford.edu
Subject: sun commonlisp 3.0.2 and in-package
Reply-To: stanonik@nprdc.navy.mil
Sorry if this has been beat to death before.
We just installed sun commonlisp 3.0.2 (from lucid) and
it now warns when files don't begin with in-package. It
warns even if in-package is preceded by provide, the order
recommended in CLtL. The explanation given is that provide/require
are useless (better to use a defsystem) and discouraged in
ansi commonlisp. I haven't kept up with ansi commonlisp,
require/provide are weak compared to defsystem, but I was
still surprised to see a warning in this case.
Ron Stanonik
stanonik@nprdc.navy.mil
∂18-Jul-89 1518 Common-Lisp-mailer Re: sun commonlisp 3.0.2 and in-package
Received: from atc.boeing.com by SAIL.Stanford.EDU with TCP; 18 Jul 89 15:18:49 PDT
Received: by atc.boeing.com on Tue, 18 Jul 89 14:43:43 PDT
Message-Id: <2825786522-9736245@QUINAULT>
Sender: SLN@QUINAULT.atc.boeing.com
Date: Tue, 18 Jul 89 14:42:02 MDT
From: Stephen Nicoud <snicoud@atc.boeing.com>
To: stanonik@nprdc.navy.mil
Cc: common-lisp@sail.stanford.edu
Subject: Re: sun commonlisp 3.0.2 and in-package
In-Reply-To: Msg of 18 July 1989 0744-PDT (Tuesday) from stanonik@nprdc.navy.mil.ARPANET (Ron Stanonik)
Organization: Boeing Advanced Technology Center for Computer Sciences
Date: 18 July 1989 0744-PDT (Tuesday)
From: stanonik@nprdc.navy.mil.ARPANET (Ron Stanonik)
Subject: sun commonlisp 3.0.2 and in-package
It
warns even if in-package is preceded by provide, the order
recommended in CLtL.
The logic for putting PROVIDE at the beginning of the file which REQUIRE
loads doesn't seem quite right. PROVIDE probably should be the last
thing evaluated after the contents of module are loaded. In that way,
if an error occurs during the loading, attempts to reuse REQUIRE, after
fixing the error, should succeed. If the recommended method were used
(putting PROVIDE first) the user would have to manually remove the
module name from *modules* before being able to reuse REQUIRE.
The explanation given is that provide/require
are useless (better to use a defsystem) and discouraged in
ansi commonlisp. I haven't kept up with ansi commonlisp,
require/provide are weak compared to defsystem, but I was
still surprised to see a warning in this case.
Ron Stanonik
stanonik@nprdc.navy.mil
PROVIDE/REQUIRE is weak. Integrating PROVIDE/REQUIRE with DEFSYSTEMs is
really interesting 8↑) depending on how you interpret the term "module".
You could use "module" to mean the system being defined by DEFSYSTEM,
the DEFSYSTEM modules, or both. There are advantages and disadvantages
to any of the interpretations (which become more dramatic if you're
trying to develop portable code).
Integrating PROVIDE/REQUIRE with DEFSYSTEMs *and* SPE's DEFMODULES
becomes an even more interesting exercise in compatibility.
Is it too optimistic to hope that there will there be an attempt to
define a Common Lisp standard for system maintenance which captures
dependencies, modules, systems, and operations on them?
Steve Nicoud
snicoud@atc.boeing.com
∂18-Jul-89 1816 Common-Lisp-mailer Re: sun commonlisp 3.0.2 and in-package
Received: from cayuga.cs.rochester.edu by SAIL.Stanford.EDU with TCP; 18 Jul 89 18:16:22 PDT
Received: from lesath.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/m) id AA22785; Tue, 18 Jul 89 21:15:02 EDT
Received: from loopback by lesath.cs.rochester.edu (3.2/m) id AA07306; Tue, 18 Jul 89 21:15:47 EDT
Message-Id: <8907190115.AA07306@lesath.cs.rochester.edu>
To: Stephen Nicoud <snicoud@atc.boeing.com>
Cc: stanonik@nprdc.navy.mil, common-lisp@sail.stanford.edu
Subject: Re: sun commonlisp 3.0.2 and in-package
In-Reply-To: Your message of Tue, 18 Jul 89 14:42:02 -0600.
<2825786522-9736245@QUINAULT>
Date: Tue, 18 Jul 89 21:15:43 -0400
From: quiroz@cs.rochester.edu
| The logic for putting PROVIDE at the beginning of the file which REQUIRE
| loads doesn't seem quite right. PROVIDE probably should be the last
| thing evaluated after the contents of module are loaded. In that way,
| if an error occurs during the loading, attempts to reuse REQUIRE, after
| fixing the error, should succeed. If the recommended method were used
| (putting PROVIDE first) the user would have to manually remove then
| module name from *modules* before being able to reuse REQUIRE.
Not as clear as it seems at first sight. LOAD could keep track of
PROVIDES and undo them on failure to complete loading. The
advantage, if anything, in putting PROVIDE first, reside in stopping
accidental indirect recursions of requirements. (That LOAD has to
keep a subjunctive environment to undo in case of failure goes along
with similar impositions on the compiler.)
On the issue of the original message, I think there is agreement
that PROVIDE-REQUIRE is not very strong, and I think everybody uses
one form of DEFSYSTEM or another anyway. But leaving
PROVIDE-REQUIRE in is a nice aspect of self-documenting coding
style. And, at any rate, *as long* as CLtL is the accepted
standard, complaining about code that is complying with it is rude.
Cesar
∂18-Jul-89 2317 Common-Lisp-mailer sun commonlisp 3.0.2 and in-package
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Jul 89 23:17:21 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA17350g; Tue, 18 Jul 89 23:14:40 PDT
Received: by bhopal id AA26340g; Tue, 18 Jul 89 23:16:32 PDT
Date: Tue, 18 Jul 89 23:16:32 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907190616.AA26340@bhopal>
To: stanonik@nprdc.navy.mil
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Ron Stanonik's message of 18 July 1989 0744-PDT (Tuesday) <8907181444.AA20259@atlantic.nprdc.navy.mil>
Subject: sun commonlisp 3.0.2 and in-package
re: We just installed sun commonlisp 3.0.2 (from lucid) and
it now warns when files don't begin with in-package. It
warns even if in-package is preceded by provide, the order
recommended in CLtL. The explanation given is that provide/require
are useless (better to use a defsystem) and discouraged in
ansi commonlisp.
I'm not sure where you got "the explanation given", but it couldn't
have been from any Lucid source. There should be documentation with
Sun Common Lisp release 3.0.2 which suggests overriding the order
of the "7 extremely randoms" recommended in CLtL, and placing the
PROVIDE statement last in the file; then, an IN-PACKAGE statement
can always be first in the file.
Incidentally, a very large number of users find PROVIDE/REQUIRE very
useful (with even fewer porting problems than many other Common Lisp
constructs, such as SUBTYPEP!). One reasonable use of REQUIRE is merely
as a "safety net" to assure that the remainder of a file isn't loaded
unless the pre-requisite facilities are available; a particularly
useful version of this is to assure that a program's "package setup"
file is loaded before proceeding with the loading of any part of
the coding. It is not a reasonable use of PROVIDE and REQUIRE to
expect them to replace a defsystem facility, although the fuzzy
language at the bottom of page 188 of CLtL seems to suggest so.
One more problem may arise with an initial IN-PACKAGE in a file.
Because of another lacuna (which the upcoming proposed ANSI Common
Lisp doesn't correct either), you have no guarantee whatsoever as to
what package an IN-PACKGE form is read into. To be on the super-safe
side, you should do something like:
(LISP:IN-PACKAGE "MY-PACKAGE-NAME")
unless you can be 100% sure that you will never be "in" a package
that doesn't "use" LISP. Note the use of a string rather than a symbol
as the package name, and note also no other arguments, implying that
the call to IN-PACKAGE *** does not *** create the package, but merely
selects it. [Yes, I know that there is at least one implementation that
has several differnt definitions of IN-PACKAGE, and they are selected by
*not* package-qualifying IN-PACKAGE in your file. Lotsa luck if you ever
load a file "by hand" rather than using their automated defsystem.]
-- JonL --
∂19-Jul-89 0636 Common-Lisp-mailer Re: sun commonlisp 3.0.2 and in-package
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 19 Jul 89 06:36:13 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aw14411; 19 Jul 89 9:35 EDT
Received: from draper.com by RELAY.CS.NET id ab21937; 19 Jul 89 9:31 EDT
Date: Wed, 19 Jul 89 08:13 EDT
From: "Steve Bacher (Batchman)" <SEB1525@ccfvx3.draper.com>
Subject: Re: sun commonlisp 3.0.2 and in-package
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: COMMON-LISP
Not to worry. The Common Lisp gang is going to get rid of PROVIDE/REQUIRE
anyhow, since most of them think it's useless and/or nonportable. It
looks like IN-PACKAGE may be redefined, if not discarded, as well.
Watch for a DEFPACKAGE macro in the next edition of CL.
∂19-Jul-89 0803 Common-Lisp-mailer Re: sun commonlisp 3.0.2 and in-package
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 19 Jul 89 08:02:58 PDT
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA08306; Wed, 19 Jul 89 11:06:06 -0400
Received: from localhost by mist. (4.0/SMI-4.0)
id AA06548; Wed, 19 Jul 89 11:01:40 EDT
Message-Id: <8907191501.AA06548@mist.>
To: "Steve Bacher (Batchman)" <SEB1525@ccfvx3.draper.com>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Re: sun commonlisp 3.0.2 and in-package
In-Reply-To: Your message of Wed, 19 Jul 89 08:13:00 -0400.
<8907191414.AA07817@multimax.encore.com>
Date: Wed, 19 Jul 89 11:01:37 EDT
From: Dan L. Pierson <pierson@mist.encore.com>
Not to worry. The Common Lisp gang is going to get rid of
PROVIDE/REQUIRE anyhow, since most of them think it's useless
and/or nonportable. It looks like IN-PACKAGE may be redefined, if
not discarded, as well. Watch for a DEFPACKAGE macro in the next
edition of CL.
Close, but not quite. The current vote status is:
Delete PROVIDE/REQUIRE. This is an extremely controversial
compromise position (which I wrote). The basic argument is:
1. The file loading behavior of REQUIRE is non-portable. Everyone
seems to agree with this.
2. In particular, a user of REQUIRE on a system which supports useful
automatic file loading (e.g. DEFSYSTEM invocation), will very
likely be unpleasantly surprised when trying to move a large
application developed on such a system to a system where
REQUIRE doesn't autoload files. The problem is that REQUIRE
can't simply be used as a safety net if it loads the file
instead of complaining. This argument is not universally accepted.
3. Many people feel that restricting PROVIDE and REQUIRE to
trivial safety net functionality reduces them to functions that
a user can trivially write. This is obviously true, but it
certainly hasn't been uniformly applied as a reason to keep
things out of Common Lisp.
4. Many implementors who do provide a REQUIRE that loads files
objected strenuously to any attempt to make their current
functionality illegal. This sort of objection carries a good
deal of weight in X3J13 because their user base would really be
hurt by the change.
5. Deleting PROVIDE/REQUIRE permits all implementations to
continue offering their current functionality while making it
clear to users that these functions are NOT portable and should
be avoided in portable code. The only required change is that
the symbols must now appear in a package other than COMMON-LISP.
IN-PACKAGE has been changed to a macro that only takes a single
argument which is a constant string. It is anticipated (but
neither stated nor required) that many implementations will make
the macro transform (IN-PACKAGE 'foo) to (IN-PACKAGE "FOO")
automatically.
This was done because the second argument to the current
IN-PACKAGE is a dangerous booby trap (ask JonL for more details)
and because X3J13 is trying to move to a clearer model of compiler
processing. Part of the compiler model effort is a drive to
minimize or eliminate the magic special compiler handling of forms
such as the "seven extremely random"s.
Personally, I think that the lack of a standard DEFSYSTEM is one of
our biggest failures in this round of the Common Lisp standards
effort. The isssue was controversial and might not have passed. None
the less, several of us are guilty of not writing up a proposal and
trying to get it through.
∂19-Jul-89 1107 Common-Lisp-mailer Re: sun commonlisp 3.0.2 and in-package
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 19 Jul 89 11:07:39 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac21059; 19 Jul 89 14:08 EDT
Received: from draper.com by RELAY.CS.NET id ab25037; 19 Jul 89 14:06 EDT
Date: Wed, 19 Jul 89 12:34 EDT
From: "Steve Bacher (Batchman)" <SEB1525@ccfvx3.draper.com>
Subject: Re: sun commonlisp 3.0.2 and in-package
To: pierson@mist.encore.com, common-lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"pierson@mist.encore.com"
Thanks for clarifications re PROVIDE/REQUIRE and IN-PACKAGE. Now, what
about DEFPACKAGE? Is that going to be reality? It's certainly preferable
in form to IN-PACKAGE, and less likely to cause breakage (since nobody is
currently using it).
∂19-Jul-89 1122 Common-Lisp-mailer Re: sun commonlisp 3.0.2 and in-package
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 19 Jul 89 11:22:41 PDT
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA14465; Wed, 19 Jul 89 14:25:47 -0400
Received: from localhost by mist. (4.0/SMI-4.0)
id AA06766; Wed, 19 Jul 89 14:21:21 EDT
Message-Id: <8907191821.AA06766@mist.>
To: "Steve Bacher (Batchman)" <SEB1525@ccfvx3.draper.com>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Re: sun commonlisp 3.0.2 and in-package
In-Reply-To: Your message of Wed, 19 Jul 89 12:34:00 -0400.
<8907191821.AA14393@multimax.encore.com>
Date: Wed, 19 Jul 89 14:21:19 EDT
From: Dan L. Pierson <pierson@mist.encore.com>
X3J13 has voted to include DEFPACKAGE in the draft standard.
I should note here that all X3J13 votes are subject to change at a
later meeting. It's not the draft standard until we send it out, etc.
However, DEFPACKAGE has a lot of support and little, if any,
opposition, so I personally expect it to be in the standard.
∂19-Jul-89 1127 Common-Lisp-mailer Re: sun commonlisp 3.0.2 and in-package
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 19 Jul 89 11:25:03 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa08878; 19 Jul 89 18:49 BST
Date: Wed, 19 Jul 89 19:05:33 BST
Message-Id: <2768.8907191805@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: sun commonlisp 3.0.2 and in-package
To: "Dan L. Pierson" <pierson%mist.encore.com@NSFnet-Relay.AC.UK>,
"Steve Bacher (Batchman)" <@uunet.uu.net:SEB1525@ccfvx3.draper.com>
In-Reply-To: Dan L. Pierson's message of Wed, 19 Jul 89 11:01:37 EDT
Cc: common-lisp@sail.stanford.edu
>> Not to worry. The Common Lisp gang is going to get rid of
>> PROVIDE/REQUIRE anyhow, since most of them think it's useless
>> and/or nonportable.
Do I detect a trace of bitterness here?
> IN-PACKAGE has been changed to a macro that only takes a single
> argument which is a constant string. It is anticipated (but
> neither stated nor required) that many implementations will make
> the macro transform (IN-PACKAGE 'foo) to (IN-PACKAGE "FOO")
> automatically.
Maybe I wasn't paying attention, because I would have voted against
allowing only a string. As far as I can tell,
(in-package :foo)
is more portable than
(in-package "FOO")
because it works even if someone has changed the internal case to
lower case (which is possible in some implementations). However,
(use-package 'foo)
can lead to problems, because it may create a symbol, FOO, which
may turn out to have been a mistake. For example, suppose I write
a file that looks like this:
(in-package "MATCH")
(export '(match match-case))
Now suppose someone writes
(use-package 'match)
A name conflict will most likely result, because the call to
USE-PACKAGE will create an internal symbol MATCH in the using
package, and that symbol will conflict with MATCH:MATCH.
-- Jeff
∂19-Jul-89 1149 Common-Lisp-mailer Re: sun commonlisp 3.0.2 and in-package
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 19 Jul 89 11:49:00 PDT
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA14911; Wed, 19 Jul 89 14:52:09 -0400
Received: from localhost by mist. (4.0/SMI-4.0)
id AA06869; Wed, 19 Jul 89 14:47:43 EDT
Message-Id: <8907191847.AA06869@mist.>
To: Jeff Dalton <"jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK"@multimax.encore.com>
Cc: common-lisp@sail.stanford.edu
Subject: Re: sun commonlisp 3.0.2 and in-package
In-Reply-To: Your message of Wed, 19 Jul 89 19:05:33 -0000.
<2768.8907191805@aiai.ed.ac.uk>
Date: Wed, 19 Jul 89 14:47:40 EDT
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Wed, 19 Jul 89 19:05:33 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Maybe I wasn't paying attention, because I would have voted against
allowing only a string. As far as I can tell,
(in-package :foo)
is more portable than
(in-package "FOO")
because it works even if someone has changed the internal case to
lower case (which is possible in some implementations). However,
(use-package 'foo)
can lead to problems, because it may create a symbol, FOO, which
may turn out to have been a mistake.
All of this was discussed, but not included in the infinite (and
rather bizare) rehashes and revotes on the original motion.
You are of course right that :foo is safer than 'foo.
I believe that the final motion only requires the new IN-PACKAGE to
accept a string.
There was a great deal of agreement with the concept that the
IN-PACKAGE macro could be written so as to accept any of: a string, a
quote symbol, or an unquoted symbol (note that the macro does not
evaluate its argument). If a symbol is supplied, the macro could
expand into code that takes the SYMBOL-NAME of the symbol and uses
that string. It was expected that this transformation would happen at
compile time in files to be compiled. The treatment of keyword and
non-keyword symbols would presumably be identical.
Note that the preceding paragraph is not part of the standard. I
don't recall anyone every proposing that we require this behavior and
some people were not convinced that it would work all that well. In
particular, it does nothing to help loading source files.
∂19-Jul-89 1457 Common-Lisp-mailer exit extent (formerly nonlocal exit from unwind-protect)
Received: from PHOENIX.SCH.Symbolics.COM ([128.81.38.192]) by SAIL.Stanford.EDU with TCP; 19 Jul 89 14:57:51 PDT
Received: from FARRAGUT.SCH.Symbolics.COM by PHOENIX.SCH.Symbolics.COM via CHAOS with CHAOS-MAIL id 90095; Wed 19-Jul-89 14:56:37 PDT
Date: Wed, 19 Jul 89 14:56 PDT
From: barmar@THINK.COM
Subject: exit extent (formerly nonlocal exit from unwind-protect)
To: Don Cohen <donc@vaxa.isi.edu>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8907180014.AA03478@vaxa.isi.edu>
Message-ID: <19890719215656.4.BARMAR@FARRAGUT.SCH.Symbolics.COM>
Date: Mon, 17 Jul 89 17:14:29 PDT
From: Don Cohen <donc@vaxa.isi.edu>
Is there any way known under the "minimal" proposal to write
an un-exitable loop? Of course, whether that's a good thing
to be able to do is another question.
No, there isn't. If something does a THROW, RETURN-FROM, or GO to a
target outside the loop then any targets used by the loop are
disestablished as soon as the transfer begins.
∂19-Jul-89 1921 Common-Lisp-mailer sun commonlisp 3.0.2 and in-package
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Jul 89 19:21:40 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA01478g; Wed, 19 Jul 89 19:19:06 PDT
Received: by bhopal id AA28414g; Wed, 19 Jul 89 19:21:16 PDT
Date: Wed, 19 Jul 89 19:21:16 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907200221.AA28414@bhopal>
To: stanonik@nprdc.navy.mil
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Jon L White's message of Tue, 18 Jul 89 23:16:32 PDT <8907190616.AA26340@bhopal>
Subject: sun commonlisp 3.0.2 and in-package
re: [JonL:] There should be documentation with
Sun Common Lisp release 3.0.2 which suggests overriding the order
of the "7 extremely randoms" recommended in CLtL, and placing the
PROVIDE statement last in the file; then, an IN-PACKAGE statement
can always be first in the file.
I'm going to have to emmend my comment here. Not all 3.0-level releases
from Lucid seem to have the same documentation with them. In particular,
the Sun3/3.0 release doesn't have the stylistic suggestions re PROVIDE
and REQUIRE, although several others do [I think someone added the
"warning" code after the first set of documentations was prepeared, but
before the final Sun3 image shipment?] If you would like these extra
pages, just let me know and I'm sure I can find some way to send them
to you, either electronically or by hardcopy.
As I mentioned before, I think PROVIDE/REQUIRE have a justifiable
use outside of the aborted defsystem debate. If that is not the
issue, but the "warning" is, then you should complain to Sun customer
support about it (or, about the lack of documentation on how to turn
it off?). In a world without PROVIDE/REQUIRE, it _certainly_ is better
style to put an IN-PACKAGE as the first form in a file; this will be the
case in the proposed ANSI Common Lisp, and is an issue independent
of DEFPACKAGE.
-- JonL --
∂20-Jul-89 0656 Common-Lisp-mailer Re: sun commonlisp 3.0.2 and in-package
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 20 Jul 89 06:56:16 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa00725; 20 Jul 89 9:55 EDT
Received: from draper.com by RELAY.CS.NET id aa00437; 20 Jul 89 9:49 EDT
Date: Thu, 20 Jul 89 07:21 EDT
From: "Steve Bacher (Batchman)" <SEB1525@ccfvx3.draper.com>
Subject: Re: sun commonlisp 3.0.2 and in-package
To: jeff%aiai.edinburgh.ac.uk@NSFNET-RELAY.AC.UK,
common-lisp@SAIL.STANFORD.EDU, pierson%mist.encore.com@NSFNET-RELAY.AC.UK
X-VMS-To: IN%"jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk"
>>> Not to worry. The Common Lisp gang is going to get rid of
>>> PROVIDE/REQUIRE anyhow, since most of them think it's useless
>>> and/or nonportable.
>
>Do I detect a trace of bitterness here?
Au contraire. Having never implemented PROVIDE or REQUIRE, I would be
just as glad to see them disappear. :-)
∂21-Aug-89 2205 Common-Lisp-mailer Condition sensitive resarts (or the lack thereof).
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 21 Aug 89 22:05:32 PDT
Return-Path: <moose@Think.COM>
Received: from odin.think.com by Think.COM; Tue, 22 Aug 89 01:07:05 EDT
Received: by odin.think.com; Tue, 22 Aug 89 01:03:25 EDT
Date: Tue, 22 Aug 89 01:03:25 EDT
From: moose@Think.COM
Message-Id: <8908220503.AA09031@odin.think.com>
To: common-lisp@sail.stanford.edu
Subject: Condition sensitive resarts (or the lack thereof).
In reading the Condition System Revision #18 document (KMP 12 Mar 88), I am
surprised to find that the proposed (adopted?) standard does not make any
provision for associating restarts with specific conditions. I don't believe
that this is the same concern as that voiced in CONDITION-RESTARTS change
(passed by X3j13 in June '88). My complaint is:
Given a something like a restart-case construct, I would like to make the
dynamically available restarts depend on the type/class of the condition
signalled. That is, if an arithmetic-error condition is signalled, I would
like to have one group of restarts active. If an illegal-throw is signalled, I
might like to have a different set of restarts available. I have in mind the
Zetalisp (Symbolics) with-proceed-cases construct.
I am at a loss as to how to build this from the available handler/restart
constructs which are described in the documents mentioned above. Any
suggestions will be appreciated.
Many thanks:
moose
Adam Greenberg
Thinking Machines Corporation
moose@think.com
∂21-Aug-89 2216 Common-Lisp-mailer Correction to my previous question.
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 21 Aug 89 22:16:10 PDT
Return-Path: <moose@Think.COM>
Received: from odin.think.com by Think.COM; Tue, 22 Aug 89 01:17:46 EDT
Received: by odin.think.com; Tue, 22 Aug 89 01:14:07 EDT
Date: Tue, 22 Aug 89 01:14:07 EDT
From: moose@Think.COM
Message-Id: <8908220514.AA09126@odin.think.com>
To: common-lisp@sail.stanford.edu
Subject: Correction to my previous question.
I inadvertently cited an imaginary feature of Zetalisp. With-proceed-cases is a
local construct. It is built on the Zetalisp catch-error-restart facility.
Apologies:
moose
∂22-Aug-89 1259 Common-Lisp-mailer Condition sensitive resarts (or the lack thereof).
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 22 Aug 89 12:55:49 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 645529; 22 Aug 89 15:57:30 EDT
Date: Tue, 22 Aug 89 15:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Condition sensitive resarts (or the lack thereof).
To: moose@Think.COM
cc: Common-Lisp@SAIL.Stanford.EDU
In-Reply-To: <8908220514.AA09126@odin.think.com>,
<8908220503.AA09031@odin.think.com>
Message-ID: <19890822195727.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Tue, 22 Aug 89 01:03:25 EDT
From: moose@Think.COM
... Given a something like a restart-case construct, I would like to make the
dynamically available restarts depend on the type/class of the condition
signalled. That is, if an arithmetic-error condition is signalled, I would
like to have one group of restarts active. ...
I believe the new :TEST option in RESTART-CASE or :TEST-FUNCTION option
in RESTART-BIND (see item #7 of proposal CONDITION-RESTARTS, version 2)
is exactly what you are looking for. e.g.,
(RESTART-CASE (ERROR SOME-CONDITION-OR-OTHER)
(FIX-ARITHMETIC-1 ()
:TEST (LAMBDA (CONDITION) (TYPEP CONDITION 'ARITHMETIC-ERROR))
...)
(FIX-ARITHMETIC-2 ()
:TEST (LAMBDA (CONDITION) (TYPEP CONDITION 'ARITHMETIC-ERROR))
...)
(FIX-CONTROL-1 ()
:TEST (LAMBDA (CONDITION) (TYPEP CONDITION 'CONTROL-ERROR))
...))
If this isn't enough to take care of your needs, please respond to me
privately saying why and maybe we can come up with something that is.
-kmp
∂25-Aug-89 1219 Common-Lisp-mailer Porting Scheme to Common Lisp
Received: from AI-SUN.jpl.nasa.gov by SAIL.Stanford.EDU with TCP; 25 Aug 89 12:19:02 PDT
Received: from AI-NEPTUNE.jpl.nasa.gov by AI-SUN.jpl.nasa.gov via CHAOS with CHAOS-MAIL id 22175; Fri 25-Aug-89 11:45:25 PDT
Date: Fri, 25 Aug 89 11:45 PDT
From: Gaius Martin <Martin@AI-SUN.jpl.nasa.gov>
Subject: Porting Scheme to Common Lisp
To: common-lisp@sail.stanford.edu
cc: Martin@AI-SUN.jpl.nasa.gov
Message-ID: <19890825184517.1.MARTIN@AI-NEPTUNE.jpl.nasa.gov>
We have a programmer here who wants to do some prototyping in Scheme.
We will eventually have to move the code to Common Lisp. I know nothing
about Scheme, so I do not know where it differs from Common Lisp. I am
looking for information and references to articles or books that compare
Scheme and Common Lisp. If anyone has done this port of Scheme to
Common Lisp before, I would like to hear of any lessons learned and any
difficulties that were encountered along the way.
Thanks for any comments and help,
Gaius
∂25-Aug-89 1249 Common-Lisp-mailer Porting Scheme to Common Lisp
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 25 Aug 89 12:49:45 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 25 Aug 89 15:50:52 EDT
Date: Fri, 25 Aug 89 15:48 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Porting Scheme to Common Lisp
To: Gaius Martin <Martin@ai-sun.jpl.nasa.gov>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <19890825184517.1.MARTIN@AI-NEPTUNE.jpl.nasa.gov>
Message-Id: <19890825194808.3.BARMAR@OCCAM.THINK.COM>
Date: Fri, 25 Aug 89 11:45 PDT
From: Gaius Martin <Martin@ai-sun.jpl.nasa.gov>
We have a programmer here who wants to do some prototyping in Scheme.
We will eventually have to move the code to Common Lisp. I know nothing
about Scheme, so I do not know where it differs from Common Lisp. I am
looking for information and references to articles or books that compare
Scheme and Common Lisp. If anyone has done this port of Scheme to
Common Lisp before, I would like to hear of any lessons learned and any
difficulties that were encountered along the way.
About the only thing Scheme has that would be difficult to reproduce in
Common Lisp is its first-class continuations, and various constructs
built on them. So, most programs that use
CALL-WITH-CURRENT-CONTINUATION (aka CALL/CC) will be difficult to port
to CL. In Scheme, the equivalents of BLOCK, CATCH, and UNWIND-PROTECT
are constructed using CALL/CC, and they are much more flexible than the
CL versions; in particular, they have indefinite extent, so you can
return from once of these constructs more than once in Scheme, while CL
only allows you to return once.
The other noticeable difference between Scheme and CL is the way
function-valued expressions are used. In CL you must write (funcall
<expr> <args>), but in Scheme you just write (<expr> <args>). And when
functions named, CL requires you to use FLET to bind local names and
(FUNCTION <name>) to reference functions by name, to indicate that the
function namespace should be used, while Scheme only has one namespace
and therefore uses ordinary LET and variable referencing. It may be
possible to transform such code from Scheme to CL automatically, but the
result probably won't be pretty, containing lots of extraneous LAMBDAs
and FUNCALLs; for instance, the code:
(let ((foo (lambda (x) (+ x x))))
...
(another-fun foo)
(foo bar))
would be translated (by a simplistic algorithm) to:
(let ((foo #'(lambda (x) (+ x x))))
...
(another-fun foo)
(funcall foo bar))
instead of the more Lispy:
(flet ((foo (x) (+ x x)))
...
(another-fun #'foo)
(foo bar))
∂25-Aug-89 1342 Common-Lisp-mailer Re: Porting Scheme to Common Lisp
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 25 Aug 89 13:42:44 PDT
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA16147; Fri, 25 Aug 89 16:46:25 -0400
Received: from localhost by mist. (4.0/SMI-4.0)
id AA01505; Fri, 25 Aug 89 16:40:26 EDT
Message-Id: <8908252040.AA01505@mist.>
To: Gaius Martin <Martin@ai-sun.jpl.nasa.gov>
Cc: common-lisp@sail.stanford.edu
Subject: Re: Porting Scheme to Common Lisp
In-Reply-To: Your message of Fri, 25 Aug 89 15:48:00 -0400.
<19890825194808.3.BARMAR@OCCAM.THINK.COM>
Date: Fri, 25 Aug 89 16:40:23 EDT
From: Dan L. Pierson <pierson@mist.encore.com>
On Fri, 25 Aug 89 15:48 EDT,
Barry Margolin <barmar@Think.COM> said:
> The other noticeable difference between Scheme and CL is the way
> function-valued expressions are used. ...
> instead of the more Lispy:
> (flet ((foo (x) (+ x x)))
> ...
> (another-fun #'foo)
> (foo bar))
However, in many Scheme systems you could define some macros and
read-macros to let the above style be accepted. This would simplify
later rewriting at the cost of outranging the aesthetic sensibilities
of any local Scheme programmers.
However, there is another aspect of the feature of Scheme that you
should be aware of. In Common Lisp a variable has two values: its
value and its function (and its property list...). In Scheme a
variable only has a single value. This means that Common Lisp code
such as the following will not work as expected in Scheme:
(defun foo (list bar)
(let ((a (cadr list)))
(list a bar)))
This shouldn't cause you too much trouble, since the danger is in
translating Common Lisp to Scheme, but you should be aware of it.
∂25-Aug-89 1703 Common-Lisp-mailer Re: Porting Scheme to Common Lisp
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 25 Aug 89 17:03:01 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 25 Aug 89 20:04:29 EDT
Date: Fri, 25 Aug 89 20:01 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: Porting Scheme to Common Lisp
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: Gaius Martin <Martin@ai-sun.jpl.nasa.gov>, common-lisp@sail.stanford.edu
In-Reply-To: <8908252040.AA01505@mist.>
Message-Id: <19890826000141.4.BARMAR@OCCAM.THINK.COM>
Date: Fri, 25 Aug 89 16:40:23 EDT
From: Dan L. Pierson <pierson@mist.encore.com>
However, in many Scheme systems you could define some macros and
read-macros to let the above style be accepted. This would simplify
later rewriting at the cost of outranging the aesthetic sensibilities
of any local Scheme programmers.
True, but irrelevant. The original question was about converting code
written by a Scheme programmer. He's not likely to want to use a bunch
of macros that make his code look like CL. If he were willing to write
code with #' and FUNCALL, he might as well use CL rather than Scheme.
barmar
∂28-Aug-89 0928 Common-Lisp-mailer Re: Porting Scheme to Common Lisp
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 28 Aug 89 09:28:07 PDT
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP
id aa07303; 28 Aug 89 17:18 BST
Date: Mon, 28 Aug 89 17:24:10 BST
Message-Id: <16958.8908281624@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: Porting Scheme to Common Lisp
To: Barry Margolin <barmar@think.com>,
Gaius Martin <Martin%ai-sun.jpl.nasa.gov@NSFnet-Relay.AC.UK>
In-Reply-To: Barry Margolin's message of Fri, 25 Aug 89 15:48 EDT
Cc: common-lisp@sail.stanford.edu
> About the only thing Scheme has that would be difficult to reproduce in
> Common Lisp is its first-class continuations, and various constructs
> built on them.
Another problem may be that Scheme guarantees that tail-recursion
will be optimized, which may not happen in Common Lisp.
∂28-Aug-89 0945 Common-Lisp-mailer Porting Scheme to Common Lisp
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 28 Aug 89 09:45:31 PDT
Received: from fafnir.think.com by Think.COM; Mon, 28 Aug 89 12:46:26 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 28 Aug 89 12:43:39 EDT
Received: by verdi.think.com; Mon, 28 Aug 89 12:43:24 EDT
Date: Mon, 28 Aug 89 12:43:24 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8908281643.AA09641@verdi.think.com>
To: jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk
Cc: barmar@Think.COM, Martin%ai-sun.jpl.nasa.gov@nsfnet-relay.ac.uk,
common-lisp@sail.stanford.edu
In-Reply-To: Jeff Dalton's message of Mon, 28 Aug 89 17:24:10 BST <16958.8908281624@aiai.ed.ac.uk>
Subject: Porting Scheme to Common Lisp
Date: Mon, 28 Aug 89 17:24:10 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
> About the only thing Scheme has that would be difficult to reproduce in
> Common Lisp is its first-class continuations, and various constructs
> built on them.
Another problem may be that Scheme guarantees that tail-recursion
will be optimized, which may not happen in Common Lisp.
Let us say, rather, that Scheme, unlike Common Lisp, is forbidden
to pessimize tail-recursion.
--Guy
∂05-Sep-89 1656 Common-Lisp-mailer Request for Lisp Applications
Received: from helen.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 5 Sep 89 16:56:35 PDT
Received: by helen.Berkeley.EDU (5.57/1.25)
id AA13170; Tue, 5 Sep 89 16:57:01 PDT
Date: Tue, 5 Sep 89 16:57:01 PDT
From: ho%helen.Berkeley.EDU@ginger.Berkeley.EDU (Kinson Ho)
Message-Id: <8909052357.AA13170@helen.Berkeley.EDU>
To: common-lisp@sail.stanford.edu
Subject: Request for Lisp Applications
Cc: ho@ginger.Berkeley.EDU
I am looking for a number of meduim size, sequential Common Lisp
programs for porting to Multiprocessing Spur Lisp. Spur Lisp is
a dialect of Common Lisp with extensions for programming on
shared memory multiprocessors.
The programs will be used in my study of high level primitives
for multiprocessing based on Spur Lisp. They should be "real"
applications that are reasonably well written (and documented).
All kinds of Lisp applications are welcome. Typical examples
include compilers, simulators (of all kinds), theorem provers,
expert systems, symbolic algebra systems, heuristic search, graph
algorithms and CAD programs.
With the permission of the authors, and subject to disk space
constraints, I may make these programs available for public ftp.
Such a collection of Lisp programs may serve as a common baseline
for groups developing parallel Lisp systems.
If you have a program that may benefit from a parallel implementation,
or know of anyone who does, please send me electronic mail.
Thanks in advance.
Kinson Ho (ho@ginger.Berkeley.EDU)
Computer Science Division
University of California, Berkeley
∂26-Oct-89 1213 Common-Lisp-mailer array-element-type = NIL
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Oct 89 12:13:22 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA28264g; Thu, 26 Oct 89 12:10:25 PDT
Received: by bhopal id AA11518g; Thu, 26 Oct 89 12:12:06 PDT
Date: Thu, 26 Oct 89 12:12:06 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8910261912.AA11518@bhopal>
To: common-lisp@sail.stanford.edu
Cc: maj@lucid.com
Subject: array-element-type = NIL
Is there any practical use for arrays with element type NIL?
Should it be an error to try to make such an array?
Note that I'm not asking what (array <n> :element-type NIL) should be
upgraded to. Rather assume that you don't upgrade the element type and
just keep it as NIL. Thus the array can't have any elements; even if
it has a non-zero size, it still can't have any elements because no
"element" can be of type NIL.
How many arrays can dance on the head of a . . .
-- JonL --
∂26-Oct-89 1301 Common-Lisp-mailer array-element-type = NIL
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 26 Oct 89 13:01:23 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Thu, 26 Oct 89 16:02:06 -0400
Date: Thu, 26 Oct 89 15:57 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: array-element-type = NIL
To: Jon L White <jonl@lucid.com>
Cc: common-lisp@sail.stanford.edu, maj@lucid.com
In-Reply-To: <8910261912.AA11518@bhopal>
Message-Id: <19891026195730.1.BARMAR@OCCAM.THINK.COM>
Character-Type-Mappings: (1 0 (NIL 0) (:FIX :ROMAN :NORMAL) "CPTFONT")
Fonts: CPTFONT, CPTFONT
Date: Thu, 26 Oct 89 12:12:06 PDT
From: Jon L White <jonl@lucid.com>
Is there any practical use for arrays with element type NIL?
Should it be an error to try to make such an array?
Genera signals an error: "ε1Attempt to make an array with :ELEMENT-TYPE
NIL, probably an errorε0". However, it doesn't detect the error when the
element type is something like (AND INTEGER FLOAT); it creates a type T
array.
Note that I'm not asking what (array <n> :element-type NIL) should be
upgraded to. Rather assume that you don't upgrade the element type and
just keep it as NIL. Thus the array can't have any elements; even if
it has a non-zero size, it still can't have any elements because no
"element" can be of type NIL.
Well, for that matter, what good is the type specifier NIL at all? You
can't declare a variable of that type, you can't declare a function
returning that type. The only thing you can do with the NIL type
specifier is use it in TYPEP (for all x, (typep x nil) is NIL),
SUBTYPEP (for all type specifiers x (subtypep nil x) => T and (subtypep
x nil) => NIL), and building type specifiers using boolean operations.
I'd say that it should be implementation-dependent. If
(array-upgraded-element-type nil) returns something non-NIL, then it is
equivalent to specifying the upgraded type; if it returns NIL, then
MAKE-ARRAY must signal an error.
barmar
∂26-Oct-89 1317 Common-Lisp-mailer Re: array-element-type = NIL
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 89 13:17:13 PDT
Received: from fred.slisp.cs.cmu.edu by FRED.SLISP.CS.CMU.EDU id aa01795;
26 Oct 89 16:15:01 EDT
To: Jon L White <jonl@lucid.com>
cc: common-lisp@sail.stanford.edu, maj@lucid.com
Subject: Re: array-element-type = NIL
In-reply-to: Your message of Thu, 26 Oct 89 12:12:06 -0700.
<8910261912.AA11518@bhopal>
Date: Thu, 26 Oct 89 16:14:54 EDT
From: Rob.MacLachlan@FRED.SLISP.CS.CMU.EDU
element-type = NIL doesn't seem very useful to me. You can't read them or
write them, which are the interesting operations on arrays. But I don't
think it should be an error to specify :element-type NIL, since MAKE-ARRAY
can return a correct result even when NIL isn't a supported specialized
element type. Since NIL is a subtype of every type, it could arbitrarily
choose any element type.
Rob
∂27-Oct-89 1658 Common-Lisp-mailer array-element-type = NIL
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 27 Oct 89 16:58:43 PDT
Received: from Fafnir.Think.COM by Think.COM; Fri, 27 Oct 89 18:00:45 -0400
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 27 Oct 89 17:56:20 EDT
Received: by verdi.think.com; Fri, 27 Oct 89 17:56:14 EDT
Date: Fri, 27 Oct 89 17:56:14 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8910272156.AA23107@verdi.think.com>
To: jonl@lucid.com
Cc: common-lisp@sail.stanford.edu, maj@lucid.com
In-Reply-To: Jon L White's message of Thu, 26 Oct 89 12:12:06 PDT <8910261912.AA11518@bhopal>
Subject: array-element-type = NIL
Date: Thu, 26 Oct 89 12:12:06 PDT
From: Jon L White <jonl@lucid.com>
Is there any practical use for arrays with element type NIL?
Should it be an error to try to make such an array?
Note that I'm not asking what (array <n> :element-type NIL) should be
upgraded to. Rather assume that you don't upgrade the element type and
just keep it as NIL. Thus the array can't have any elements; even if
it has a non-zero size, it still can't have any elements because no
"element" can be of type NIL.
How many arrays can dance on the head of a . . .
A very interesting point indeed. Consider a similar question:
does
(DECLARE (TYPE NIL FOO))
mean that FOO never has a value? You can redundantly MAKUNBOUND it,
but you can't do much else.
If so, then I agree with your interpretation.
But if that declaration is illegal, then I argue that an array
whose element-type is NIL could still be meaningful but its total-size
must be zero.
A third position is that NIL is always an invalid element-type.
∂28-Oct-89 1901 Common-Lisp-mailer array-element-type = NIL
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Oct 89 19:01:42 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA08914g; Sat, 28 Oct 89 18:58:46 PDT
Received: by bhopal id AA11973g; Sat, 28 Oct 89 19:00:42 PDT
Date: Sat, 28 Oct 89 19:00:42 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8910290200.AA11973@bhopal>
To: barmar@Think.COM, Rob.MacLachlan@FRED.SLISP.CS.CMU.EDU,
gamble@ptolemy.arc.nasa.gov, gls@Think.COM
Cc: common-lisp@sail.stanford.edu, maj@lucid.com
In-Reply-To: Jon L White's message of Thu, 26 Oct 89 12:12:06 PDT <8910261912.AA11518@bhopal>
Subject: array-element-type = NIL
Rob writes: "Since NIL is a subtype of every type, it could arbitrarily
choose any element type."
The trouble with choosing anything other than NIL is that it breaks
monotonicity of the UPGRADED-ARRAY-ELEMENT-TYPE function. [Well, it
"probably" breaks it; only an unreasonable implementation would have
some specialized array type for these losers that _didn't_ have actual
element type NIL; upgrading to element type T of course would surely be
a different specialized array type, even in a bad implementation.]
On the other hand signaling an error, even when limited to the case of
array-total-size being non-zero, seems to make the function discontinuous
and "singular" about :element-type NIL. The reason I've been leaning
towards this singularity solution is that upgrading to T seemed preferable
only if there were going to be a real use for it.
Evan Gamble makes a case for allowing the type to be legal, even though
no elements could actually be stored in the array (his note, sent to me
privately, is copied below). This seems to be the logically consistent
thing to do, but it has the implemtational consequence that an actual,
new specialized array type would have to be added to the system to
accommodate it. [Lucid Common Lisp currently allows :element-type NIL
iff the total size is 0, and signals an error otherwise; no new
specialized type is needed here -- it is just special-cased, so to speak].
Date: Thu, 26 Oct 89 16:09:11 PDT
From: Evan Gamble <gamble@ptolemy.arc.nasa.gov>
To: jonl@lucid.com
Subject: array-element-type = NIL
JonL,
I believe that it is sometimes useful to make a language "complete" in
the sense of allowing seemingly useless, pathological, or degenerate
cases, like arrays with :element-type nil, for the following reason.
If I have a bunch of data of different types, and some of them will
cause my function to have degenerate or "useless" values, but I don't
want to take the trouble to filter out the troublemakers, there is no
reason to force me to do so. For instance, I might write a function
which takes a type specifier as an argument and produces an array with
that :element-type. If I then apply it to a bunch of pre-existing
type specifiers (say for an object-oriented system I'm developing) I
would be upset if I were forced to specifically filter out the type
nil, when it is an otherwise perfectly valid type.
There are many similar "useless" but "useful" cases in CL. For
instance, why would anyone want to evaluate (and) ? It is useful to
me that it is defined in CL because programs which generate "and"
expressions do not have to handle the empty case specially.
Evan
P.S. I don't know the procedure for posting to this mailing list (I
don't often post things). Could you post this for me?
-- JonL --
∂30-Oct-89 1305 Common-Lisp-mailer array-element-type = NIL
Received: from WHITE.SWW.Symbolics.COM ([128.81.57.24]) by SAIL.Stanford.EDU with TCP; 30 Oct 89 13:05:03 PST
Received: from CHROME.SWW.Symbolics.COM by WHITE.SWW.Symbolics.COM via CHAOS with CHAOS-MAIL id 28804; Mon 30-Oct-89 13:01:01 PST
Date: Mon, 30 Oct 89 13:00 PST
From: mArQ lE bRuN <MLB@WHITE.SWW.Symbolics.COM>
Subject: array-element-type = NIL
To: jonl@lucid.com
cc: common-lisp@sail.stanford.edu, maj@lucid.com, discuss-lisp@WHITE.SWW.Symbolics.COM
In-Reply-To: <8910261912.AA11518@bhopal>
Message-ID: <19891030210017.2.MLB@CHROME.SWW.Symbolics.COM>
[this is my personal opinion and does not necessarily reflect those of my employers or
colleagues]
Date: Thu, 26 Oct 89 12:12:06 PDT
From: Jon L White <jonl@lucid.com>
Is there any practical use for arrays with element type NIL?
I know of no actual current uses of this specific thing.
I can certainly make up some hypothetical ones for you, however. Such an array does have
dimensions and can apparently have a fill-pointer and it can be displaced (albeit only to
other type NIL arrays). Thus a number of array operators remain meaningful and error-free
(even if potentially worthless) when given such an array. If only to allow simple and safe
boundary conditions one might expect these to remain valid.
A plausible use for such an object is as a placeholder for a "real" array. Everything in a
program could pretty much "just work" (eg CHECK-TYPE) except operations which depended on the
actual elements of the array (as opposed to its "arrayness").
In fact, I have for several years used similar (although differently implemented) placeholder
arrays in some applications I maintain. These arrays are normally "displaced" to hardware at
physical addresses on our system's bus. However saving a binary image of a Lisp containing
such arrays to disk is dangerous, because the machine it is later booted on may have the
hardware at a different place, or it may even be entirely absent, resulting in bus errors,
system crashes and, worst of all, user bug reports. Therefore such arrays are tracked, and
are automatically "invalidated" before saves by indirecting them to a placeholder array, which
gets errors if accessed, but otherwise doesn't cause problems (actually I use zero length
arrays, but the principle applies).
Further, in extended Lisp systems built over CL, placeholder arrays may have additional uses.
For example in Symbolics Lisp arrays are the substrate used for implementing structures. One
could at least imagine using NIL type vectors in some (possibly degenerate) structures in some
applications. (In my application I give the placeholders type symbols that try to help
explain why they are invalid).
Also, there may be more permissive versions of adjust-array or even just array indirection
that would make NIL type array placeholders easier to use (eg if you are allowed to indirect
to subtypes of your type, rather than to the exact same type, as in CLtL).
Should it be an error to try to make such an array?
No. Everything that isn't explicitly forbidden should be permitted.
However I sympathize with implementations (including Symbolics') that punt by erroring on
this, since if you allow such arrays you have to somehow be able to detect the invalid
accesses to them that may happen later.
But from a pure-language perspective I don't think it's right.
Note that I'm not asking what (array <n> :element-type NIL) should be
upgraded to. Rather assume that you don't upgrade the element type and
just keep it as NIL. Thus the array can't have any elements; even if
it has a non-zero size, it still can't have any elements because no
"element" can be of type NIL.
"Upgrading" such an array would be a worse folly than erroring anyway.
How many arrays can dance on the head of a . . .
(Ask rather: how many pinheads can dance in arrays?)
-- JonL --
∂31-Oct-89 1701 Common-Lisp-mailer :DISPLACED-TO & :DISPLACED-INDEX-OFFSET.
Received: from atc.boeing.com ([130.42.28.80]) by SAIL.Stanford.EDU with TCP; 31 Oct 89 17:00:45 PST
Received: by atc.boeing.com on Tue, 31 Oct 89 15:31:37 PST
Date: Tue, 31 Oct 89 15:37 PST
From: Stephen Nicoud <snicoud@atc.boeing.com>
Subject: :DISPLACED-TO & :DISPLACED-INDEX-OFFSET.
To: common-lisp@sail.stanford.edu
Message-Id: <19891031233708.3.SLN@SKAGIT.atc.boeing.com>
Hello!
I have some questions concerning the :DISPLACED-TO and
:DISPLACED-INDEX-OFFSET options to MAKE-ARRAY for '(UNSIGNED-BYTE X)
elements.
I. Given the following forms:
(setq A (make-array 4 :element-type '(unsigned-byte 1)))
(setq B (make-array 2 :element-type '(unsigned-byte 2) :displaced-to A))
If the element types of A and B are not considered the same, CLtL
(pg. 288) would seem to suggest B's MAKE-ARRAY call is an error, so
...
Is B a valid array?
Is the answer different if A were displaced to B?
Are all '(UNSIGNED-BYTE X) arrays considered to be of the same
'array' type and thus 'displacable' to each other?
II. If the element types are the same, and I specify the
:DISPLACED-INDEX-OFFSET argument like this:
(setq A (make-array 4 :element-type '(unsigned-byte 1)))
(setq B (make-array 1 :element-type '(unsigned-byte 2) :displaced-to A
:displaced-index-offset 1))
Does the :DISPLACED-INDEX-OFFSET refer to the number of
'(UNSIGNED-BYTE 2) or '(UNSIGNED-BYTE 1) elements to offset?
III. Is it allowed to displace to a displaced array? That is, is the
following valid?
(setq A (make-array 4 :element-type '(unsigned-byte 4)))
(setq B (make-array 8 :element-type '(unsigned-byte 2) :displaced-to A))
(setq C (make-array 16 :element-type '(unsigned-byte 1) :displaced-to B))
IV. Bonus question: What about :displaced-index-offset to displaced
arrays? Given:
(setq A (make-array 4 :element-type '(unsigned-byte 4)))
(setq B (make-array 4 :element-type '(unsigned-byte 2) :displaced-to A
:displaced-index-offset 1))
(setq C (make-array 4 :element-type '(unsigned-byte 1) :displaced-to B
:displaced-index-offset 1))
Does the :DISPLACED-INDEX-OFFSET for C refer to the number of A, B or
C's :element-types to offset?
Steve Nicoud
snicoud@atc.boeing.com
∂01-Nov-89 0650 Common-Lisp-mailer Re: :DISPLACED-TO & :DISPLACED-INDEX-OFFSET.
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Nov 89 06:50:01 PST
Received: from fred.slisp.cs.cmu.edu by FRED.SLISP.CS.CMU.EDU id aa06347;
1 Nov 89 9:47:15 EST
To: Stephen Nicoud <snicoud@atc.boeing.com>
cc: common-lisp@sail.stanford.edu
Subject: Re: :DISPLACED-TO & :DISPLACED-INDEX-OFFSET.
In-reply-to: Your message of Tue, 31 Oct 89 15:37:00 -0800.
<19891031233708.3.SLN@SKAGIT.atc.boeing.com>
Date: Wed, 01 Nov 89 09:46:19 EST
From: Rob.MacLachlan@FRED.SLISP.CS.CMU.EDU
Although not clearly stated, "same type" has the normal interpretation in
this context. (unsigned-byte 1) and (unsigned-byte 2) are not the same
type, so you cannot displace between arrays with these types. Some
implementations (such as the Lisp Machine) do allow such displacing, but I
don't know the exect interpretation they give. In any case, a conforming
Common Lisp program cannot do such displacing.
Rob
∂01-Nov-89 1052 Common-Lisp-mailer :DISPLACED-TO & :DISPLACED-INDEX-OFFSET.
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 89 10:52:19 PST
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA08376g; Wed, 1 Nov 89 10:49:17 PST
Received: by bhopal id AA00929g; Wed, 1 Nov 89 10:51:13 PST
Date: Wed, 1 Nov 89 10:51:13 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8911011851.AA00929@bhopal>
To: snicoud@atc.boeing.com
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Stephen Nicoud's message of Tue, 31 Oct 89 15:37 PST <19891031233708.3.SLN@SKAGIT.atc.boeing.com>
Subject: :DISPLACED-TO & :DISPLACED-INDEX-OFFSET.
The problem with the specification on p288 -- "... does not have the
same :element-type" -- is that there is an ambiguity in the meaning
of the :element-type. See CLtL p45 where explicit permission is
given to "upgrade" the requested element type in a call to make-array.
Thus whether or not:
(make-array 4 :element-type '(unsigned-byte 1))
(make-array 4 :element-type '(unsigned-byte 2))
are both upgraded into the same underlying element-type is very much
implementation dependent. The X3J13 committee -- which is making
a recommendation for an ANSI standard for Common Lisp -- voted in
a proposal ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING which
clarified this notion.
Now, since the real restriction against displacing to arrays with
differing element types is based on the potential for "endian"
mismatch, then you can be sure that there is no mismatch when
both requests produce the same sort of specialized array. But
if the underlying sizes of "chunks" necesary to hold the elements
aren't the same, then it makes a difference how two n-bit chunks
are packed into a single 2n-bit chunk. E.g., is it
+---------+---------+
|<index-o>|<index-1>|
+---------+---------+
or is it
+---------+---------+
|<index-1>|<index-0>|
+---------+---------+
Thus it is even reasonable for an implementation to permit displacement
to an array with a different underlying element-size, but this would
not be portable becauses the indices would have a significantly different
meaning in an implementation with a different "endianness". In fact,
since the element-type upgrading scheme is implementation-dependent, then
the only portable displacements are to those arrays whose element-type
specifiers are equivalent over all implementations. Of course,
(unsigned-byte 1) and (unsigned-byte 2) are not type-equivalent, since
there are easily some implementations which will merge them into a
single specialized array type, and other implementations that will
make different specialized array types for each one.
In answer to your second question:
Does the :DISPLACED-INDEX-OFFSET refer to the number of
'(UNSIGNED-BYTE 2) or '(UNSIGNED-BYTE 1) elements to offset?
I think CLtL p288 makes it clear that the :DISPLACED-INDEX-OFFSET
is in units of the array to which the displacement is being made.
[Last paragraph: "It is required that the total size of A (the array
being displaced to) be no smaller than the sum of the total size of
B plus the offset n specified by the :DISPLACED-INDEX-OFFSET argument.]
Note however it is presuming that the sizes of the "chunks" necessary
to store elements from the two arrays is the same.
re: III. Is it allowed to displace to a displaced array?
Yes.
re: IV. Bonus question: What about :displaced-index-offset to displaced
arrays?
This is trivial when you assume that all the underlying element sizes are
the same. It only becomes an interesting question when they are different;
and in this case, you are treading on waters of non-portability. I would
think, however, that a simple relation can be derived by transitivity
after you have established the constraints and relations between the
two individual displacements:
A displaced-to B ;figure out offsets etc
B displaced-to C ;figure out offsets etc
thus for the relation between A's units and C's, you should be able
to cascade the two individual relations is some obvious way.
-- JonL --
∂01-Nov-89 1135 Common-Lisp-mailer :DISPLACED-TO & :DISPLACED-INDEX-OFFSET.
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 1 Nov 89 11:35:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 685649; 1 Nov 89 14:33:56 EST
Date: Wed, 1 Nov 89 14:33 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: :DISPLACED-TO & :DISPLACED-INDEX-OFFSET.
To: Jon L White <jonl@lucid.com>, snicoud@atc.boeing.com
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8911011851.AA00929@bhopal>
Message-ID: <19891101193358.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 1 Nov 89 10:51:13 PST
From: Jon L White <jonl@lucid.com>
In answer to your second question:
Does the :DISPLACED-INDEX-OFFSET refer to the number of
'(UNSIGNED-BYTE 2) or '(UNSIGNED-BYTE 1) elements to offset?
I think CLtL p288 makes it clear that the :DISPLACED-INDEX-OFFSET
is in units of the array to which the displacement is being made.
[Last paragraph: "It is required that the total size of A (the array
being displaced to) be no smaller than the sum of the total size of
B plus the offset n specified by the :DISPLACED-INDEX-OFFSET argument.]
Note however it is presuming that the sizes of the "chunks" necessary
to store elements from the two arrays is the same.
In Symbolics' extension that allows displacement to an array with a
different element-type, the :DISPLACED-INDEX-OFFSET is in units of the
array to which the option is applied, not in units of the :DISPLACED-TO
array. I imagine the same is true of TI's similar extension, although
I did not check this. As you say, in strict Common Lisp the two units
must be the same, so the issue does not arise.
Yes, multilevel displaced arrays of differing types work in the obvious
way, again as an extension; strict Common Lisp requires all the types
to be the same. It's possible to construct a multilevel displaced
array that cannot be AREF'ed because the combined displaced index
offset is not an integral multiple of the array element size.
Symbolics' extension proves to be extremely useful for certain
inherently machine-dependent operations, but I would not recommend
trying to add it to the portable language. As you say, it is inherently
dependent on the machine's data representation.
∂01-Nov-89 1332 Common-Lisp-mailer :DISPLACED-TO & :DISPLACED-INDEX-OFFSET.
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 89 13:32:11 PST
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA09060g; Wed, 1 Nov 89 13:28:31 PST
Received: by bhopal id AA01668g; Wed, 1 Nov 89 13:30:24 PST
Date: Wed, 1 Nov 89 13:30:24 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8911012130.AA01668@bhopal>
To: jonl@lucid.com
Cc: snicoud@atc.boeing.com, common-lisp@sail.stanford.edu
In-Reply-To: Jon L White's message of Wed, 1 Nov 89 10:51:13 PST <8911011851.AA00929@bhopal>
Subject: :DISPLACED-TO & :DISPLACED-INDEX-OFFSET.
Ooops, my message ignored the "accidental" equivalence of the types
(ARRAY BIT) and (ARRAY (UNSIGNED-BYTE 1)). CLtL p29 explicitly requires
that specialized array types be provided for arrays of element type
BIT and STRING-CHAR.
Just convert the type-specifiers in that msg as follows
(UNSIGNED-BYTE 1) ==> (UNSIGNED-BYTE 2)
(UNSIGNED-BYTE 2) ==> (UNSIGNED-BYTE 4)
and it is all technically correct again.
Thanks to Eric Benson for pointing this out.
-- JonL --
∂09-Nov-89 0938 Common-Lisp-mailer make-echo-stream & unread-char
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 9 Nov 89 09:38:29 PST
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa09616; 9 Nov 89 16:32 GMT
Received: from psune by syma.sussex.ac.uk; Thu, 9 Nov 89 16:31:31 GMT
Message-Id: <12178.8911091633@psune.cogs.susx.ac.uk>
From: John Williams <johnw%cogs.sussex.ac.uk@NSFnet-Relay.AC.UK>
Date: Thu, 9 Nov 89 16:33:24 GMT
To: common-lisp@sail.stanford.edu
Subject: make-echo-stream & unread-char
If you 'unread' a character to an echo-stream, then should
that character be echoed again when it is read again?
I ask because my implementation of READ uses UNREAD-CHAR to 'unread'
terminating macro characters when they are read as the terminator
to a token. This means that if you READ an echo-stream terminating
macro chars (e.g. "(") get echoed twice.
John Williams,
Dept. of Cognitive and Computing Sciences, University of Sussex, UK
∂10-Nov-89 1131 Common-Lisp-mailer make-echo-stream & unread-char
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Nov 89 11:31:48 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 690324; 10 Nov 89 14:30:37 EST
Date: Fri, 10 Nov 89 14:30 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: make-echo-stream & unread-char
To: johnw%cogs.sussex.ac.uk@NSFnet-Relay.AC.UK
cc: common-lisp@sail.stanford.edu
In-Reply-To: <12178.8911091633@psune.cogs.susx.ac.uk>
Message-ID: <19891110193017.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 9 Nov 89 16:33:24 GMT
From: John Williams <johnw%cogs.sussex.ac.uk@NSFnet-Relay.AC.UK>
If you 'unread' a character to an echo-stream, then should
that character be echoed again when it is read again?
CLtL is not adequately specific. ANSI Common Lisp will take a position
on this. Briefly (because this is a large list), the position will
likely be that the character is echoed the first time it is seen on the
stream, and not re-echoed later.
Note that ANSI Common Lisp is not a standard yet--it's not even a draft
standard. The position of X3J13 (the ANSI CL commitee) on this issue
could change between now and the time the standard is approved. Also
note that any decisions by X3J13 are not binding on implementations of
CLtL. It is perfectly legitimate for a correct `implementation of CLtL'
to differ in interpretation on an issue such as this from what would be
necessary in a correct `implementation of ANSI CL' (whatever that might
turn out to be). So nothing forces you to go with the X3J13
interpretation of this situation--but it's not a bad idea to go with it
for expected-future-compatibility's sake if nothing keeps you from doing so.
-kmp
∂13-Nov-89 0957 Common-Lisp-mailer put me on the mailing list
Received: from gateway.mitre.org by SAIL.Stanford.EDU with TCP; 13 Nov 89 09:57:42 PST
Return-Path: <vogel@starbase.mitre.org>
Received: by gateway.mitre.org (5.54/SMI-2.2)
id AA04664; Mon, 13 Nov 89 13:01:06 EST
Received: by starbase (4.0/SMI-4.0)
id AA25064; Mon, 13 Nov 89 12:54:21 EST
Date: Mon, 13 Nov 89 12:54:21 EST
From: vogel@starbase.mitre.org (David Vogel)
Message-Id: <8911131754.AA25064@starbase>
To: common-lisp@sail.stanford.edu
Subject: put me on the mailing list
Please. Thank you.
∂14-Nov-89 1255 Common-Lisp-mailer Test Message
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 14 Nov 89 12:55:04 PST
Received: from daystar.aca.mcc.com by MCC.COM with TCP/SMTP; Tue 14 Nov 89 14:22:27-CST
Date: Tue, 14 Nov 89 14:22:20 CST
From: loeffler@daystar.aca.mcc.com (David Loeffler)
Posted-Date: Tue, 14 Nov 89 14:22:20 CST
Message-Id: <8911142022.AA15313@daystar.aca.mcc.com>
Received: by daystar.aca.mcc.com (3.2/ACTv4.1i)
id AA15313; Tue, 14 Nov 89 14:22:20 CST
To: Common-Lisp@mcc.com, Common-Lisp-Object-system@mcc.com, Cl-windows@mcc.com,
CL-Cleanup@mcc.com
Subject: Test Message
This is a test message. Please disregard it. We are testing a new
host for distributing mail on these lists. This message is just a test
to see how well the mailer handles distributing the mail.
Thank you.
∂17-Nov-89 1020 Common-Lisp-mailer CLX toolkit and/or CLUE Contact "classes/libraries"
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 17 Nov 89 10:18:28 PST
Received: from atc.boeing.com by MCC.COM with TCP/SMTP; Fri 17 Nov 89 12:02:30-CST
Received: by atc.boeing.com on Fri, 17 Nov 89 10:02:26 PST
Received: by tieton.atc.boeing.com (3.2/SMI-3.0DEV3)
id AA01890; Fri, 17 Nov 89 10:02:31 PST
Date: Fri, 17 Nov 89 10:02:31 PST
From: aseem@atc.boeing.com
Message-Id: <8911171802.AA01890@tieton.atc.boeing.com>
To: CommonLoops.pa@xerox.com, clue-review@dsg.csc.ti.com, common-lisp@mcc.com,
common0-lisp-object-system@mcc.com
Subject: CLX toolkit and/or CLUE Contact "classes/libraries"
Are there any CLX toolkits and/or CLUE Contact "libraries"
available (commercially or publically) which provide a set
of basic interactive objects like buttons, scrollbars, menus,
forms, text etc.
I am looking at writing an interface using CLUE and do not
wish to build up the interface components from scratch using
CLX.
aseem@atc.boeing.com
206-865-3225
∂19-Dec-89 1206 Common-Lisp-mailer address change
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 19 Dec 89 12:06:29 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 19 Dec 89 13:52:37-CST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Dec 89 11:51:29 PST
Received: from rose ([192.31.212.83]) by lucid.com id AA19170g; Tue, 19 Dec 89 08:48:02 PST
Received: by rose id AA17764g; Tue, 19 Dec 89 08:50:39 PST
Date: Tue, 19 Dec 89 08:50:39 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8912191650.AA17764@rose>
To: X3J13@sail.stanford.edu, common-lisp@sail.stanford.edu
Subject: address change
LISP AND SYMBOLIC COMPUTATION: An International Journal
and
X3J13 Business
Please send future correspondence, submissions and reviews to me at the
following address:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
jlz@lucid.com
415/329-8400 x5509
I will be in transit for 3 weeks after Christmas arriving January 15.
---jan---
∂12-Jan-90 1124 Common-Lisp-mailer destructive operations
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 12 Jan 90 11:23:59 PST
Received: from daystar.aca.mcc.com by MCC.COM with TCP/SMTP; Fri 12 Jan 90 13:05:39-CST
Posted-Date: Tue, 09 Jan 90 15:14:58 PST
Message-Id: <9001121905.AA02195@daystar.aca.mcc.com>
Received: by daystar.aca.mcc.com (4.0/ACAv4.1i)
id AA02195; Fri, 12 Jan 90 13:05:35 CST
To: common-lisp@mcc.com
Subject: destructive operations
Date: Tue, 09 Jan 90 15:14:58 PST
From: Don Cohen <donc@vaxa.isi.edu>
Sender: loeffler@daystar.aca.mcc.com
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 9 Jan 90 17:15:27-CST
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:14:42 PST
Posted-Date: Tue, 09 Jan 90 15:14:58 PST
Message-Id: <9001092315.AA16001@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
id AA16001; Tue, 9 Jan 90 15:15:04 -0800
To: common-lisp@sail.stanford.edu
Subject: destructive operations
Date: Tue, 09 Jan 90 15:14:58 PST
From: Don Cohen <donc@vaxa.isi.edu>
I've seen some discussion lately (on lisp newsgroups) of the
fact that CLtL promises very little about destructive operations.
For instance, it looks like delete could be defined as remove.
In particular, there's no requirement of maximal structure sharing.
While this might allow some optimization in some implementations,
I think that the assumption of maximal sharing is important in
a lot of cases. This means that in those cases it becomes
necessary to write your own versions of the destructive functions.
(Worse still, since MOST implementations do maximally share
structure, it's real easy to write non-portable code without even
realizing it!)
The cases I have in mind involve purposely shared structure.
For instance, I might use list structure to represent a "semantic
net", where there are many pointers to the same structure. I'd
like to be able to do a destructive operation on the structure I
get by following one path and assume that the change affects the
(originally same) structure that I reach by another path. For
instance, suppose I do:
(setq a '(1 2 3 4 5))
(setq b (nthcdr 2 a))
Suppose I "know" that neither a nor b starts with 4. After
(delete 4 a)
I'd like to be able to assume that b no longer contains 4.
Is this unreasonable? If so, why? If there's really a great
potential for optimization in the absence of my requirement,
perhaps commonlisp should offer two versions (or another argument)
of destructive operations. If not, the maximal sharing ought to
be specified.
∂12-Jan-90 1145 CL-Cleanup-mailer TEST message from Postmaster
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 12 Jan 90 11:45:26 PST
Received: from daystar.aca.mcc.com by MCC.COM with TCP/SMTP; Fri 12 Jan 90 13:22:45-CST
Date: Fri, 12 Jan 90 13:22:39 CST
Posted-Date: Fri, 12 Jan 90 13:22:39 CST
Message-Id: <9001121922.AA02205@daystar.aca.mcc.com>
Received: by daystar.aca.mcc.com (4.0/ACAv4.1i)
id AA02205; Fri, 12 Jan 90 13:22:39 CST
To: CL-Cleanup@mcc.com, CL-Window@mcc.com, Common-Lisp@mcc.com,
Common-Lisp-Object-System@mcc.com
Subject: TEST message from Postmaster
From: Common-Lisp-Request@mcc.com
Sender: loeffler@daystar.aca.mcc.com
Reply-To: Common-Lisp-Request@mcc.com
Please disregard this message. It is being send as a test to see how
many addresses the mailer bounces.
∂12-Jan-90 1222 Common-Lisp-mailer destructive operations
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 12 Jan 90 12:21:53 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Fri 12 Jan 90 14:11:56-CST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 721935; 12 Jan 90 14:48:48 EST
Date: Fri, 12 Jan 90 14:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: destructive operations
To: Don Cohen <donc@vaxa.isi.edu>
cc: common-lisp@mcc.com
In-Reply-To: <9001121905.AA02195@daystar.aca.mcc.com>
Message-ID: <19900112195105.8.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Tue, 09 Jan 90 15:14:58 PST
From: Don Cohen <donc@vaxa.isi.edu>
I've seen some discussion lately (on lisp newsgroups) of the
fact that CLtL promises very little about destructive operations.
For instance, it looks like delete could be defined as remove.
In particular, there's no requirement of maximal structure sharing.
While this might allow some optimization in some implementations,
I think that the assumption of maximal sharing is important in
a lot of cases. This means that in those cases it becomes
necessary to write your own versions of the destructive functions.
(Worse still, since MOST implementations do maximally share
structure, it's real easy to write non-portable code without even
realizing it!)
The cases I have in mind involve purposely shared structure.
For instance, I might use list structure to represent a "semantic
net", where there are many pointers to the same structure. I'd
like to be able to do a destructive operation on the structure I
get by following one path and assume that the change affects the
(originally same) structure that I reach by another path. For
instance, suppose I do:
(setq a '(1 2 3 4 5))
(setq b (nthcdr 2 a))
Suppose I "know" that neither a nor b starts with 4. After
(delete 4 a)
I'd like to be able to assume that b no longer contains 4.
In ANSI Common Lisp, the value of B after that call to DELETE is
unspecified. According to issue REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89,
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
Thus DELETE is permitted to perform arbitrary SETF operations on the
CAR and CDR of the three conses that make up B.
Is this unreasonable? If so, why?
More quotations from REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89:
Implementations already vary widely on their implementation techniques
for these functions. This effectively clarifies the status quo, making
it more clear to programmers what they may rely upon in portable code.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion.
If there's really a great
potential for optimization in the absence of my requirement,
perhaps commonlisp should offer two versions (or another argument)
of destructive operations. If not, the maximal sharing ought to
be specified.
I am not sure that you can specify precisely, unambiguously, and
independent of implementation what you are asking to be guaranteed
about these functions. In any case, my guess is that the Common Lisp
designers (including X3J13) felt that the type of programming practice
you are proposing is rarely enough used that it isn't appropriate to
add additional features to the language in support of it. It's not
too hard to write your own functions in terms of CAR and RPLACD. Of
course your point that this is a portability trap is a good point.
Common Lisp does contain several portability traps like this (although
I think Common Lisp contains fewer portability traps than C).
∂12-Jan-90 1331 Common-Lisp-mailer destructive operations
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 12 Jan 90 13:31:34 PST
Received: from vaxa.isi.edu by MCC.COM with TCP/SMTP; Fri 12 Jan 90 15:18:37-CST
Posted-Date: Fri, 12 Jan 90 12:47:12 PST
Message-Id: <9001122047.AA26595@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
id AA26595; Fri, 12 Jan 90 12:47:17 -0800
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Subject: destructive operations
Cc: common-lisp@mcc.com
Date: Fri, 12 Jan 90 12:47:12 PST
From: Don Cohen <donc@vaxa.isi.edu>
In ANSI Common Lisp, the value of B after that call to DELETE is
unspecified.
That's even worse than I thought.
According to issue REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89,
Where can I get this and other such discussions?
I am not sure that you can specify precisely, unambiguously, and
independent of implementation what you are asking to be guaranteed
about these functions.
It's quite possible that the easiest specification is the code.
In any case, my guess is that the Common Lisp
designers (including X3J13) felt that the type of programming practice
you are proposing is rarely enough used that it isn't appropriate to
add additional features to the language in support of it.
If so, I'd disagree. In fact, it's often hard to tell whether you're
relying on this sort of behavior until you meet an implementation that
doesn't have it. Also, I don't really believe that the current state
of affairs is quite as chaotic as the quotation suggests. I bet my
example would work in every lisp I've ever used, although I'd have
to change the name of the delete function several times. I also fail
to see the great opportunity for optimization in this and related cases.
∂12-Jan-90 1402 Common-Lisp-mailer destructive operations
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 12 Jan 90 14:02:08 PST
Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Fri 12 Jan 90 15:35:03-CST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 722042; 12 Jan 90 16:32:25 EST
Date: Fri, 12 Jan 90 16:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: destructive operations
To: Don Cohen <donc@vaxa.isi.edu>
cc: common-lisp@mcc.com
In-Reply-To: <9001122047.AA26595@vaxa.isi.edu>
Message-ID: <19900112213433.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Fri, 12 Jan 90 12:47:12 PST
From: Don Cohen <donc@vaxa.isi.edu>
According to issue REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89,
Where can I get this and other such discussions?
The easiest way would be for you to contact whoever in your organization
is a member of the X3J13 standards committee.
I am not sure that you can specify precisely, unambiguously, and
independent of implementation what you are asking to be guaranteed
about these functions.
It's quite possible that the easiest specification is the code.
Code is never a good specification, since there is no way to know which
aspects of the code were intended to be part of the specification and
which aspects of the code were mere accidents. For example, when you
write code you have to give specific names to internal functions and
variables, you have to choose a specific order in which to perform all
operations, and you have to either omit all optimizations or write
code that is hard to read. It's unlikely that by doing that you meant
to specify that those names must be used, that order must be followed
slavishly, and no optimizations are permitted. The only way code makes
a good specification is when you actually intend to specify that every
implementation must be implemented exactly the same way.
∂12-Jan-90 1430 Common-Lisp-mailer destructive operations
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 12 Jan 90 14:30:30 PST
Received: from Think.COM by MCC.COM with TCP/SMTP; Fri 12 Jan 90 16:19:23-CST
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Fri, 12 Jan 90 17:17:39 -0500
Date: Fri, 12 Jan 90 17:17 EST
From: Barry Margolin <barmar@Think.COM>
Subject: destructive operations
To: Don Cohen <donc@vaxa.isi.edu>
Cc: common-lisp@mcc.com
In-Reply-To: <9001121905.AA02195@daystar.aca.mcc.com>
Message-Id: <19900112221724.5.BARMAR@OCCAM.THINK.COM>
Date: Tue, 09 Jan 90 15:14:58 PST
From: Don Cohen <donc@vaxa.isi.edu>
instance, suppose I do:
(setq a '(1 2 3 4 5))
(setq b (nthcdr 2 a))
Suppose I "know" that neither a nor b starts with 4. After
(delete 4 a)
I'd like to be able to assume that b no longer contains 4.
Is this unreasonable? If so, why? If there's really a great
potential for optimization in the absence of my requirement,
perhaps commonlisp should offer two versions (or another argument)
of destructive operations. If not, the maximal sharing ought to
be specified.
Dave Moon already gave a pretty good answer; I just want to add a point
that I'm surprised he didn't make. The problem with heaping lots of
requirements on the functions is that it prevents a number of
implementation-specific optimizations. For instance, when deleting an
element of a cdr-coded list, maintaining optimal sharing may result in
poorer paging performance.
I'm not sure that any of the cdr-coded implementations actually
implement such an optimization, but I know that Symbolics uses different
implementations of NREVERSE for cdr-coded and normal lists (for normal
lists (eq (last x) (nreverse x)) is true (it reverses the cdr chains),
while for cdr-coded lists (eq x (nreverse x)) is true (it swaps the
elements)). They may also use different algorithms for SORT, but I'm
not sure (if they don't, they probably want to keep the option open).
Since we didn't want to require multiple versions, we (X3J13) opted for
the one that allows the implementors the most flexibility and
opportunity to optimize. Note, however, that we did not do this for all
the destructive functions; there are some where we actually strengthened
the requirement over what CLtL specifies. See the file
arisia.xerox.com:/cl/cleanup/passed/remf-destruction-unspecified for all
the specifications.
barmar
∂12-Jan-90 1450 Common-Lisp-mailer destructive operations
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 12 Jan 90 14:49:31 PST
Received: from Think.COM by MCC.COM with TCP/SMTP; Fri 12 Jan 90 16:28:09-CST
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Fri, 12 Jan 90 17:26:06 -0500
Date: Fri, 12 Jan 90 17:25 EST
From: Barry Margolin <barmar@Think.COM>
Subject: destructive operations
To: Don Cohen <donc@vaxa.isi.edu>
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp@mcc.com
In-Reply-To: <9001122047.AA26595@vaxa.isi.edu>
Message-Id: <19900112222557.7.BARMAR@OCCAM.THINK.COM>
Date: Fri, 12 Jan 90 12:47:12 PST
From: Don Cohen <donc@vaxa.isi.edu>
I bet my
example would work in every lisp I've ever used, although I'd have
to change the name of the delete function several times.
Is this a discussion about DELETE or about destructive operations on
lists in general? At the present time, you're probably right about
DELETE. But as I mentioned in my previous message, the same argument
cannot be made about many of the other destructive functions, which
don't even behave consistently within a particular implementation.
barmar
∂12-Jan-90 1522 Common-Lisp-mailer Re: destructive operations
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 12 Jan 90 15:22:32 PST
Received: from Princeton.EDU by MCC.COM with TCP/SMTP; Fri 12 Jan 90 16:38:13-CST
Received: from winnie.Princeton.EDU by Princeton.EDU (5.58+++/2.29/mailrelay)
id AA18823; Fri, 12 Jan 90 17:36:03 EST
Received: by winnie (4.12/1.96)
id AA27734; Fri, 12 Jan 90 17:36:25 est
Date: Fri, 12 Jan 90 17:36:25 est
From: eliot@winnie.Princeton.EDU (eliot handelman)
Message-Id: <9001122236.AA27734@winnie>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, donc@vaxa.isi.edu
Subject: Re: destructive operations
Cc: common-lisp@mcc.com
>unspecified. According to issue REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89,
Where are these documents to be found?
--eliot
∂14-Jan-90 0023 Common-Lisp-mailer destructive operations - a few replies
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 14 Jan 90 00:23:38 PST
Received: from vaxa.isi.edu by MCC.COM with TCP/SMTP; Sun 14 Jan 90 01:55:49-CST
Posted-Date: Sat, 13 Jan 90 23:49:23 PST
Message-Id: <9001140749.AA28814@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
id AA28814; Sat, 13 Jan 90 23:49:27 -0800
Subject: destructive operations - a few replies
To: barmar@Think.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp@mcc.com
Date: Sat, 13 Jan 90 23:49:23 PST
From: Don Cohen <donc@vaxa.isi.edu>
I am not sure that you can specify precisely, unambiguously, and
independent of implementation what you are asking to be guaranteed
about these functions.
How about, for delete on a list, that only cdrs of the argument are
altered, specifically cdrs that originally pointed to things to be
deleted are altered to point to the next element not to be deleted,
and that the first cdr (generally the zero'th) not pointing to an
element to be deleted is returned.
I suspect similar specs are not hard for other destructive operations.
Code is never a good specification, ...
I was suggesting that some reasonable piece of code would universally
suffice. Since you want to be picky, I'll be happy to specify that
all I need is "operationally equivalent" code - you shouldn't be able
to tell from accessing the resulting state that you did anything
different from the supplied definition. This does not constrain internal
names, timing, space usage, etc. (In the absence of multiple processes
it leaves a lot of leeway on ordering, but there are more serious
problems associated with concurrency.)
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion.
If that's the case, as I suggested, please supply another version that
I can use when I care. The solution of making me (and everyone else who
ever needs it) write his own is certainly one approach, but not the one
taken by commonlisp or any of the other lisps it was trying to unify.
See the file
arisia.xerox.com:/cl/cleanup/passed/remf-destruction-unspecified for all
the specifications.
Thanks (for a whole gold mine...).
I notice that this file contains a few specs I like, viz., nconc,
nsubstitute, and quite a few like delete that I don't.
Since we didn't want to require multiple versions, we (X3J13) opted...
My suggestion of a new keyword or new function does not REQUIRE multiple
versions - only if you want to supply an optimized version that doesn't
meet the additional requirements. I'm surprised that you'd try to avoid
this situation. It's not as if it's been avoided in the past. How about
stable-sort?
∂15-Jan-90 0800 Common-Lisp-mailer destructive operations - a few replies
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 Jan 90 07:59:55 PST
Received: from Think.COM by MCC.COM with TCP/SMTP; Mon 15 Jan 90 09:49:39-CST
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Mon, 15 Jan 90 10:49:29 -0500
Date: Mon, 15 Jan 90 10:49 EST
From: Barry Margolin <barmar@Think.COM>
Subject: destructive operations - a few replies
To: common-lisp@mcc.com
In-Reply-To: <9001140749.AA28814@vaxa.isi.edu>
Supersedes: <9001150622.AA01323@odin.think.com>
Comments: Retransmission of failed mail.
Message-Id: <19900115154921.1.BARMAR@OCCAM.THINK.COM>
Date: Sat, 13 Jan 90 23:49:23 PST
From: Don Cohen <donc@vaxa.isi.edu>
See the file
arisia.xerox.com:/cl/cleanup/passed/remf-destruction-unspecified for all
the specifications.
Thanks (for a whole gold mine...).
I notice that this file contains a few specs I like, viz., nconc,
nsubstitute, and quite a few like delete that I don't.
Thank you. Originally, the proposal was wishy-washy about all the
functions. I tightened up NCONC, NSUBSTITUTE and a couple others. I
believe my justifications for tightening up particular functions is in that
file.
Since we didn't want to require multiple versions, we (X3J13) opted...
My suggestion of a new keyword or new function does not REQUIRE multiple
versions - only if you want to supply an optimized version that doesn't
meet the additional requirements. I'm surprised that you'd try to avoid
this situation. It's not as if it's been avoided in the past. How about
stable-sort?
We didn't consciously avoid specifying multiple variants; this is the first
time I've heard it suggested for DELETE (but I wasn't on the subcommittee
that originally wrote the above proposal, so I don't know whether it came
up during their earlier deliberations, but I think it would have been
mentioned in the Discussion section if it had); I know we considered such
options in other parts of the language (we generally opted against them,
since CL is already considered too big and complex by many people). We
were trying to clarify the original intent of the CL designers, which was
that these functions be specified no more precisely than is necessary for
them to be useful, and that the destructive functions be permitted extra
space optimizations. I tightened up NCONC because I think it is used only
for its well known side effect, and NSUBSTITUTE because the implementation
is so simple and obvious that it goes without saying (but nothing in a
standard should go without saying, so I said it). I've never seen a Lisp
implementation where the specific behavior of DELETE was documented, so it
didn't seem as if there was precedent for tightening up this particular
function spec, and I could conceive of implementations where such a
requirement would prevent reasonable optimizations.
barmar
∂15-Jan-90 1208 Common-Lisp-mailer Change my email address please
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 Jan 90 12:08:52 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Mon 15 Jan 90 13:34:04-CST
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 15 Jan 90 11:33:12 PST
Received: from relay2.cs.net by RELAY.CS.NET id am13154; 15 Jan 90 13:33 EST
Received: from gte.com by RELAY.CS.NET id ac24838; 15 Jan 90 14:30 EST
Received: from centauri.gte.com (centauri) by bunny.gte.com (4.41/GTEL1.13)
id AA08223; Mon, 15 Jan 90 14:26:04 EST
Date: Mon, 15 Jan 90 14:26 EST
From: Mark Weissman <mw06%centauri@gte.com>
Subject: Change my email address please
To: common-lisp@SAIL.STANFORD.EDU, cl-windows@SAIL.STANFORD.EDU
Message-Id: <19900115192645.5.MW06@centauri.gte.com>
Hello,
Could someone please change my email address on this
list from weissman@apollo.com to weissman@bunny.gte.com.
Thanks,
Mark Weissman
∂16-Jan-90 0056 Common-Lisp-mailer X3J13 cleanup issues
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 16 Jan 90 00:55:56 PST
Received: from arisia.Xerox.COM by MCC.COM with TCP/SMTP; Tue 16 Jan 90 02:38:10-CST
Received: from omnibus.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA26036; Tue, 16 Jan 90 00:04:50 -0800
Received: by omnibus.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA02084; Tue, 16 Jan 90 00:11:43 PST
Message-Id: <9001160811.AA02084@omnibus.parc.xerox.com>
Date: Tue, 16 Jan 90 00:11:43 PST
To: common-lisp@mcc.com
Cc: loosemore@cs.utah.edu
Subject: X3J13 cleanup issues
In-Reply-To: DonC's request for X3J13 discussions...
From: Larry Masinter <masinter@parc.xerox.com>
Sender: masinter@parc.xerox.com
Reply-To: masinter@parc.xerox.com
The common lisp cleanup issues (and some other related material) is
available for anonymous FTP from arisia.xerox.com, in the directory
tree under "cl". For example, cl/cleanup/passed has those cleanup
issues that were passed in previous meetings.
Caveats:
** I'm behind. I haven't finished updating the issues passed at the
last (November '89) meeting...
** None of this is 'official': this is my personal archive of what I
think passed at previous meetings, and, in any case, X3J13 has been
known to reverse itself.
** there are a number of items voted in by X3J13 that are not included
in this archive, including the CLOS spec (available elsewhere on
arisia), LOOP, the condition system. The subdirectories for compiler,
character, etc. are unreliable (old and not maintained).
I'm (sporadically) working on a mail archive server for cleanup
issues and other material; until that's done, anonymous ftp is the
best way to access this material.
I think Sandra Loosemore has been keeping the "compiler" subcommittee
issues more up to date, on cs.utah.edu.
∂01-Feb-90 1025 Common-Lisp-mailer Lisp and Symbolic Computation.
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 1 Feb 90 10:25:20 PST
Received: from atc.boeing.com by MCC.COM with TCP/SMTP; Thu 1 Feb 90 12:05:16-CST
Received: by atc.boeing.com on Thu, 1 Feb 90 10:05:03 PST
Date: Thu, 1 Feb 90 10:12 PST
From: Stephen Nicoud <snicoud@atc.boeing.com>
Subject: Lisp and Symbolic Computation.
To: common-lisp@mcc.com
Message-Id: <19900201181240.4.SLN@SKAGIT.atc.boeing.com>
Would someone pass on information about subscribing to "Lisp and
Symbolic Computation" and "Lisp Pointers"?
Thanks,
Steve
--
Stephen Nicoud <snicoud@atc.boeing.com> uw-beaver!bcsaic!snicoud
Boeing Advanced Technology Center for Computer Sciences
∂02-Feb-90 0506 Common-Lisp-mailer Re: Lisp and Symbolic Computation.
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Feb 90 05:06:29 PST
Received: from mcsun.EU.net by MCC.COM with TCP/SMTP; Fri 2 Feb 90 06:54:23-CST
Received: by mcsun.EU.net via EUnet; Fri, 2 Feb 90 13:54:03 +0100 (MET)
Received: from prl.philips.co.uk by kestrel.Ukc.AC.UK with UUCP id aa20826;
2 Feb 90 10:54 GMT
Received: from apollo01.prl.philips.co.uk by prlhp1.prl.philips.co.uk; Fri, 2 Feb 90 10:27:37 gmt
From: Ashok Gupta <gupta@prl.philips.co.uk>
Date: Fri, 2 Feb 90 09:09:46 gmt
Message-Id: <337.9002020909@apollo54.prl.philips.co.uk>
To: snicoud@atc.boeing.com
Subject: Re: Lisp and Symbolic Computation.
Cc: common-lisp@mcc.com
"Lisp and Symbolic Computation, An International Journal",
published by Kluwer, Editors-in-Chief Gabriel and Steele.
ISSN 0892-4635.
Subscription orders can be sent to:
Kluwer Academic Publishers
P.O. Box 358
Accord Station
Hingham, MA 02018-0358
$137 for institutions, $55 for individuals.
"Lisp Pointers" :-
Published quarterly, no charge for subscription. To get on to the mailing-
list, write to :-
LISP POINTERS
Mary S. Van Deusen, Editor
IBM Watson Research
PO Box 704
Yorktown Heights
NY 10598
USA
∂02-Feb-90 0635 Common-Lisp-mailer RE: Lisp and Symbolic Computation.
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Feb 90 06:35:08 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 2 Feb 90 08:27:58-CST
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 2 Feb 90 06:27:13 PST
Received: from relay2.cs.net by RELAY.CS.NET id ag10534; 2 Feb 90 8:27 EST
Received: from draper.com by RELAY.CS.NET id ab17207; 2 Feb 90 9:26 EST
Date: Fri, 2 Feb 90 07:53 EST
From: "Steve Bacher (Batchman)" <SEB1525@ccfvx3.draper.com>
Subject: RE: Lisp and Symbolic Computation.
To: snicoud@ATC.BOEING.COM, common-lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"snicoud@atc.boeing.com"
"Lisp and Symbolic Computation" is available from
:
Kluwer Academic Publishers
P.O. Box 358
Accord Sta.
Hingham, MA 02018-0358
(617) 871-6600
Subscription rate is $60.00 for an individual subscription, or $130.00 for
an institutional one (in US dollars - rates may differ for other countries).
"LISP Pointers" is published by
Sorry, I'd give you info on "LISP Pointers" but all my copies are at home.
In the past it was put out by a different company each issue, but I think
that now it's being disseminated by one. I'll try to remember to get the
info for you over the weekend.
- Steve Bacher
- Charles Stark Draper Lab
∂02-Feb-90 1003 Common-Lisp-mailer Lisp and Symbolic Computation.
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Feb 90 10:03:37 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 2 Feb 90 11:56:19-CST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Feb 90 09:55:04 PST
Received: from kent-state ([192.31.212.24]) by heavens-gate.lucid.com id AA20777g; Fri, 2 Feb 90 09:55:10 PST
Received: by kent-state id AA02314g; Fri, 2 Feb 90 09:49:51 PST
Date: Fri, 2 Feb 90 09:49:51 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <9002021749.AA02314@kent-state>
To: SEB1525@ccfvx3.draper.com
Cc: snicoud@ATC.BOEING.COM, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: "Steve Bacher (Batchman)"'s message of Fri, 2 Feb 90 07:53 EST <9002021436.AA19444@lucid.com>
Subject: Lisp and Symbolic Computation.
Lisp Pointers will be distributed through ACM/SIGPLAN beginning this year.
More details to come. When ACM members receive their renewal forms, they
will show a line for Lisp Pointers. It is my understanding that the
current readership will not have to re-subscribe. Currently, I've been
directing subscription requests to the general editor Mary van Deusen;
her electronic address is maida@ibm.com.
-- JonL --
∂02-Feb-90 1132 Common-Lisp-mailer Lisp and Symbolic Computation.
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Feb 90 11:32:13 PST
Received: from Think.COM by MCC.COM with TCP/SMTP; Fri 2 Feb 90 13:22:58-CST
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by Think.COM; Fri, 2 Feb 90 11:19:12 -0500
Date: Fri, 2 Feb 90 11:19 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Lisp and Symbolic Computation.
To: Stephen Nicoud <snicoud@atc.boeing.com>
Cc: common-lisp@mcc.com
In-Reply-To: <19900201181240.4.SLN@SKAGIT.atc.boeing.com>
Message-Id: <19900202161900.0.BARMAR@OCCAM.THINK.COM>
Date: Thu, 1 Feb 90 10:12 PST
From: Stephen Nicoud <snicoud@atc.boeing.com>
Would someone pass on information about subscribing to "Lisp and
Symbolic Computation" and "Lisp Pointers"?
"Lisp Pointers" is now an ACM SIGPLAN publication, so you subscribe to
it through ACM. I don't know who to contact re Lisp and Symbolic
Computation.
barmar
∂23-Feb-90 1331 Common-Lisp-mailer Interest in large Common Lisp object-oriented programs...
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 23 Feb 90 13:31:33 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 23 Feb 90 15:20:40-CST
Received: from boulder.Colorado.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 90 13:19:51 PST
Return-Path: <zorn@frost.Colorado.EDU>
Received: by boulder.Colorado.EDU (cu-hub.890824)
Received: by frost.colorado.edu (cu.generic.890828)
Message-Id: <9002232119.AA19198@frost.colorado.edu>
To: common-lisp@sail.stanford.edu
Subject: Interest in large Common Lisp object-oriented programs...
Date: Fri, 23 Feb 90 14:19:46 +0000
From: Benjamin Zorn <zorn@frost.Colorado.EDU>
I'm interested in getting copies of several large Common Lisp programs
that make extensive use of CLOS-defined objects. I am interested in
measuring the way in which objects are used and contrasting Lisp
object-oriented programming with more traditional Lisp programming
styles. Any application area would be of interest, but I am
especially interested in memory and computation intensive applications
as opposed to interactive editors, browsers and the like. In exchange
for providing me with a copy of your program, I can tell you things
about it's memory-system behavior that may be hard to determine
otherwise (object lifespan distribution, allocation rates, object size
distribtion, etc). If you know of any such programs, please let me
know. Thank you.
Benjamin Zorn
University of Colorado, Boulder
∂15-Mar-90 1418 Common-Lisp-mailer ANSI CL Spec
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 Mar 90 14:18:52 PST
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Thu 15 Mar 90 15:59:07-CST
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 15 Mar 90 13:58:03 PST
Received: from Fafnir.Think.COM by Think.COM; Thu, 15 Mar 90 16:58:28 -0500
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 15 Mar 90 16:56:54 EST
Received: by verdi.think.com; Thu, 15 Mar 90 16:58:20 EST
Date: Thu, 15 Mar 90 16:58:20 EST
From: gls@Think.COM (Guy Steele)
Message-Id: <9003152158.AA25893@verdi.think.com>
To: CommonLoops@Xerox.com, common-lisp@sail.stanford.edu
Cc: GLS@Think.COM
Subject: ANSI CL Spec
Date: Wed, 14 Mar 90 06:08 PST
From: Bruce Esrig <oravax!esrig@wrath.cs.cornell.edu>
To: commonloops-request.PA
Subject: ANSI CL Spec
Is Steele, 2nd ed. the current best presentation of ANSI Common Lisp ?
Bruce Esrig
esrig%oravax.uucp@cu-arpa.cs.cornell.edu
Perhaps the following text, excerpted from the preface to the
second edition of "Common Lisp: The Language", will shed some
light on the intended relationship of that book to the standard:
----------------------------------------------------------------
X3J13 has completed the bulk of its technical work in rectifying the
1984 definition and codifying extensions to that definition that have
received widespread use and approval. A draft standard is now being
prepared; it will probably be available in 1990. There will then be a
period (required by ANSI) for public review. X3J13 must then consider
the comments it receives and respond appropriately. If the comments
result in substantial changes to the draft standard, multiple public
review periods may be required before the draft can be approved as an
American National Standard.
Fortunately, X3J13 has done an outstanding job of documenting its
work. ... By my count, by June 1989 some 186 [proposals] were
approved as language changes....
The purpose of this second edition is to bridge the gap between the
first edition and the forthcoming ANSI standard for Common Lisp.
Because of the requirement for formal public review, it will be some
time yet before the ANSI standard is final. This book in no way
resembles the forthcoming standard (which is being written
independently by Kathy Chapman of Digital Equipment Corporation with
assistance from the X3J13 Drafting Subcommittee).
I have incorporated into this second edition a great deal of material
based on the votes of X3J13, in order to give the reader a picture of
where the language is heading. My purpose here is not simply to quote
the X3J13 documents verbatim but to paraphrase them and relate them to
the structure of the first edition. A single vote by X3J13 may be
discussed in many parts of this book, and a single passage of this
book may be affected by many of the votes.
I wish to be very clear: this book is not an official document of
X3J13, though it is based on publicly available material produced by
X3J13. In no way does this book constitute a definitive description
of the forthcoming ANSI standard. The committee's decisions have been
remarkably stable (it has rescinded earlier decisions only two or
three times), and I do not expect radical changes in direction.
Nevertheless, it is quite probable that the draft standard will be
substantively revised in response to editorial review or public
comment. I have therefore reported here on the actions of X3J13 not
to inscribe them in stone, but to make clear how the language of the
first edition is likely to change. I have tried to be careful in my
wording to avoid saying ``the language has been changed'' and to state
simply that ``X3J13 voted at such-and-so time to make the following
change.''
Until the day when an official ANSI Common Lisp standard emerges, it
is likely that the 1984 definition of Common Lisp will continue to be
used widely. This book has been designed to be used as a reference
both to the 1984 definition and to the language as modified by the
actions of X3J13.
----------------------------------------------------------------
--Guy Steele
∂02-Apr-90 1446 Common-Lisp-mailer SETF VALUES "not a difficult task"
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Apr 90 14:46:31 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Mon 2 Apr 90 16:25:35-CDT
Received: from ti.com by SAIL.Stanford.EDU with TCP; 2 Apr 90 14:24:32 PDT
Received: by ti.com id AA00615; Mon, 2 Apr 90 14:46:46 -0500
Received: from vdle8 by tilde id AA22197; Mon, 2 Apr 90 14:37:36 CDT
Message-Id: <2848073839-3374082@vdle8>
Sender: FARROW@vdle8.csc.ti.com
Date: Mon, 2 Apr 90 14:37:19 CDT
From: Rob Farrow <Farrow@vdle8.csc.ti.com>
To: gls@think.com
Cc: common-lisp@sail.stanford.edu
Subject: SETF VALUES "not a difficult task"
You stated on page 129 of CL 2nd ed. that user defined SETF VALUES
is not a difficult task. I've been having trouble solving this
non-difficult task in several UNIX based Common LISPs. On an EXPLORER,
the below implementation works.
(define-setf-method values (&rest places)
(let ((g (gensym)))
(values nil nil (list g)
`(multiple-value-setq ,places ,g)
g)))
But in two prominent Common LISPs (which I will leave nameless), this
will not. I was even told by one vendor that this potentially cannot be
done. The EXPLORER uses a superset of CL so I cannot depend on it.
Neither can I depend of the macro expansion on the vendor LISPs to be
correct.
I would greatly appreciate some clarification.
1. Should this work?
2. If not, could you send me a version which should work?
I will take these results to the vendor so the bug can be fixed.
Thank you.
P.S. Note that the above implementation does not account for nested
generalized variables (not a difficult task).
∂04-Apr-90 1355 Common-Lisp-mailer Call for contribution: A "CLOS Report" Publication
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 4 Apr 90 13:54:59 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 4 Apr 90 15:35:55-CDT
Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 4 Apr 90 13:34:38 PDT
Received: from hplap.hpl.hp.com by hplms2.hpl.hp.com with SMTP
(15.11.1.3/15.5+IOS 3.20) id AA02906; Wed, 4 Apr 90 13:35:17 pdt
Received: from localhost by hplap.HPL.HP.COM; Wed, 4 Apr 90 13:34:59 pdt
Full-Name: Andreas Paepcke
Message-Id: <9004042034.AA11896@hplap.HPL.HP.COM>
To: commonloops.pa@xerox.com, common-lisp-object-system@sail.stanford.edu,
common-lisp@sail.stanford.edu
Subject: Call for contribution: A "CLOS Report" Publication
X-Mailer: mh6.5
Date: Wed, 04 Apr 90 13:34:57 PDT
From: Andreas Paepcke <paepcke@hplap.hpl.hp.com>
With the standardization of chapters 1 and 2 done and people slaving away
at building applications, I feel it is time to make CLOS more accessible to
people with various degrees of interest. I am therefore soliciting your
help in working towards a publication to accomplish this.
I have in mind a collection of papers by members of the CLOS community,
which would be published in a place where it is easiliy available to a
broad audience. This serves the purpose both of popularizing CLOS and of
ensuring recognition for the contributors.
The appendix of this message contains a draft of the collection's
categorization. I am now looking for participation and/or suggestions to
get this project off the ground. Examples:
* Does the categorization make sense?
* Do you recommend an existing paper to be
reprinted in the collection?
* Would you like to contribute a new paper?
* Do you know of someone else who might be able to
contribute?
* Can you volunteer to help with the editing process?
If you can produce a paper, I would very much like to hear from you
informally soon. It is enough to explain which category you want to address
and very roughly what you have in mind. This will make planning a lot
easier because it will help me decide which contributions I must actively
reach out for to get coverage. Please help me gather some of this data by
the end of April.
As a separate project, I am organizing this year's CLOS Users and
Implementors Workshop to be held in the context of OOPSLA '90. I will send
out the call for participation as soon as the OOPSLA administration gives a
green light. This should be by May 28. Even though the Workshop is separate
from the publication described here, there will be linkage in that work
done for the Workshop can find its way into the publication.
Hoping to hear from you soon,
Andreas
Hewlett-Packard Laboratory
Palo Alto, Ca 94304
paepcke@hplabs.hp.com
415-857-7398
;;;;;;;;;;;;;;;;;;;; Categorization Draft ;;;;;;;;;;;;;;;;;;;;;;;;;
%-----------------------------------------------------
% Summary Categorization of Papers
%---------------------------------
Prologue: What is it like to build a language?
Short introduction to CLOS
Applications
Contrasting CLOS with other languages
CLOS Analysis and Discussion
CLOS implementations
Open research issues
Glossary
Annotated Bibliography
Index over all papers
Author Index
Prologue: What is it like to build a language?
----------------------------------------------
Audience: General, not necessarily CLOS or even language-oriented.
Example contents:
- How were existing languages used as blueprints?
- How was the design effort organized?
- Comments on PCL's implementation and distribution.
- Honestly: Was CLOS designed top-down, bottom-up, upside-down,
inside-out or without any of the fashionable CASE disciplines?
- How did the standardization process work? Any advice for others who
want to standardize something?
Short introduction to CLOS:
---------------------------
Very top level, a few pages that make a casual reader aware of what CLOS is
about. If someone has heard the term "CLOS" a lot and wants to know what it
is, this should be the place to go to.
Example contents:
- The five CLOS building blocks.
- A few programming examples.
- Maybe the architecture (MOP concept).
- References to more in-depth sources.
Applications:
-------------
Contributions in this category should go into some depth. While some parts
could be accessible to a casually browsing audience, other parts of the
contributions should satisfy a more serious reader who is considering the
use of CLOS for her own purposes.
Example contents:
- What does the application do?
- Why was CLOS chosen as the implementation language in the first place?
- Where did CLOS shine for the application, where did it weaken or fail?
There might be a discussion of how other languages would have worked
out for this particular application.
- How did the language affect the application design?
- How is the application delivered? (ex: Is there a small CLOS delivery
kernel?)
Contrasting CLOS with other languages:
--------------------------------------
Contributions may be arbitrarily complex and specialized, although it would
be good to have one or two papers accessible to an interested computer
scientist who knows some other object-oriented language and wants an easy
way of finding the correct mental pigeon hole for CLOS.
It would be nice if contributions were dialectic. Maybe two or more authors
with violently different opinions could get together and produce one
sharp-edged discussion.
Example contents:
- Strong and weak points of CLOS vs. other languages.
- Classification of languages along a particular theme (ex: realization
of functional programming, extensibility, oop philosophy,
speed/functionality tradeoffs, etc.)
- Classification of applications by which languages would be optimal for
their realizations.
CLOS Analysis and Discussion:
-----------------------------
This is for very CLOS-specific contributions. Like papers in the "language
contrasting" category, possibly combative, but *technical* pro/con flames
combined into one paper would be interesting if they help to focus a
reader's attention on some CLOS aspect.
Example contents:
- Was the MOP a good idea?
- Is the MOP-level class hierarchy sensible?
- What were the CLOS architectural tradeoffs? Why were particular
alternatives chosen?
- Which tradeoffs were resolved to CLOS' detriment.
CLOS implementations:
---------------------
This is to be a non-commercial category. Papers may point out
implementation issues, even if the author(s) have not produced any
implementation themselves.
Example contents:
- Which parts of CLOS are easy to implement, which are hard?
- Are there clever optimization opportunities?
- Are there language aspects that should have been defined differently,
given the experience gained from an actual implemention process.
Open research issues:
---------------------
The audience for papers in this category would be a competent computer
scientist looking for something to do.
Example contents:
- Anything
Glossary:
---------
Short definitions of CLOS terms.
Annotated Bibliography:
-----------------------
This is to cover the range from casual interest to very specific CLOS
issues. It would be nice if this could be a union of the bibliographies
of the papers.
Index
-----
Terms, concepts, etc. covering all the papers.
Author Index
------------
Names and addresses
∂04-Apr-90 2030 Common-Lisp-mailer common-lisp for a 386 machine
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 4 Apr 90 20:30:46 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 4 Apr 90 22:22:09-CDT
Received: from Forsythe.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Apr 90 20:21:04 PDT
Received: by Forsythe.Stanford.EDU; Wed, 4 Apr 90 20:21:46 PDT
Received: from kean.ucs.mun.ca by kean.ucs.mun.ca with mail11; id 00109571;
version Mailer V3.4; 05 Apr 90 00:40 -0330
Date: 05 Apr 90 00:36 -0330
Message-ID: <0109563@leif.mun.ca>
From: michael9%kean.ucs.mun.ca@Forsythe.Stanford.EDU
To: common-lisp@sail.stanford.edu
X-Vms-To: IN%"common-lisp@sail.stanford.edu"
Subject: common-lisp for a 386 machine
I have been using Gold Hill Common-Lisp V3.1 on a 386 machine
for the past year or two. Unfortunately this is a 16-bit
implementation. Does anyone know of a faster common-lisp that will
run on a 386? If not, what seems to be the best system-implementation
combination for the necessarily budget minded?
Mike Rabinowitz ... "MICHAEL9@MUN"
∂05-Apr-90 0831 Common-Lisp-mailer C to LISP translator/compiler?
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Apr 90 08:31:08 PDT
Received: from atc.boeing.com by MCC.COM with TCP/SMTP; Thu 5 Apr 90 10:18:09-CDT
Received: by atc.boeing.com on Thu, 5 Apr 90 08:18:15 PDT
Received: by gallium. (4.0/SMI-4.0)
id AA16309; Thu, 5 Apr 90 08:12:50 PDT
Date: Thu, 5 Apr 90 08:12:50 PDT
From: nicholls@gallium.boeing.com (William H. Nicholls)
Message-Id: <9004051512.AA16309@gallium.>
To: common-lisp@mcc.com, info-ti-explorer@sumex.aim.stanford.edu,
slug@ai.sri.com
Subject: C to LISP translator/compiler?
Does anyone know if a translator exists to convert C into
Lisp? I've heard of one going the other way......
---------
William H. Nicholls - nicholls@atc.boeing.com
Boeing Defense & Space Group - nicholls@ee.washington.edu
(let ((*standard-disclaimers* t)) ... )
∂05-Apr-90 0844 Common-Lisp-mailer common-lisp for a 386 machine
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Apr 90 08:44:05 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Thu 5 Apr 90 10:26:33-CDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Apr 90 08:25:27 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 773238; 5 Apr 90 10:40:55 EDT
Date: Thu, 5 Apr 90 10:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: common-lisp for a 386 machine
To: michael9%kean.ucs.mun.ca@Forsythe.Stanford.EDU
cc: common-lisp@sail.stanford.edu
In-Reply-To: <0109563@leif.mun.ca>
Message-ID: <19900405144620.8.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Contact a Symbolics sales person and ask about Cloe, a
Common Lisp for 386/486 machines running MS/DOS or Unix.
∂10-Apr-90 1840 Common-Lisp-mailer Re: Call for contribution: A "CLOS Report" Publication
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 10 Apr 90 18:40:21 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 10 Apr 90 20:31:41-CDT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Apr 90 18:30:34 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 10 APR 90 18:12:43 PDT
Date: Tue, 10 Apr 90 18:11 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Call for contribution: A "CLOS Report" Publication
To: Andreas Paepcke <paepcke@hplap.hpl.hp.com>
cc: commonloops.pa@Xerox.COM, common-lisp-object-system@sail.stanford.edu,
common-lisp@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest
In-Reply-To: <9004042034.AA11896@hplap.HPL.HP.COM>
Message-ID: <19900411011133.2.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Heya, I have a slightly altered version of what a CLOS book might
be like that I would like to talk to you about. In person would
be best, the bandwidth is better that way.
This plan has some advantages: it really focuses on the mop (the most
different part of CLOS), it involves fewer people (easier to
coordinate), it can really produce a book (more bang for buck). It also
has some disadvantages, namely it takes more work.
Tomorrow (wednesday) I will be at home in the morning (till about 11)
and then in my office until about 5.
-------
∂11-Apr-90 1358 Common-Lisp-mailer Re: Call for contribution: A "CLOS Report" Publication
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 11 Apr 90 13:58:10 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 11 Apr 90 15:41:15-CDT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Apr 90 13:40:02 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 90 13:35:45 PDT
Date: Wed, 11 Apr 90 13:34 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Call for contribution: A "CLOS Report" Publication
To: commonloops.pa@Xerox.COM, common-lisp-object-system@sail.stanford.edu,
common-lisp@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest
In-Reply-To: <19900411011133.2.GREGOR@SPIFF.parc.xerox.com>
Message-ID: <19900411203426.8.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
I want to apologize to the many hundreds of people who, because of my
ineptitude, received copies of a message I meant to send only to Andreas
Paepcke.
Gregor
-------
∂17-Apr-90 1607 Common-Lisp-mailer En/Decryption code?
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 17 Apr 90 16:04:36 PDT
Received: from crash.cs.umass.edu by MCC.COM with TCP/SMTP; Tue 17 Apr 90 17:43:31-CDT
Received: from vax3.cs.umass.edu by crash.cs.umass.edu (5.61/Ultrix2.0-B)
id AA00976; Tue, 17 Apr 90 18:43:25 -0400
Message-Id: <9004172243.AA00976@crash.cs.umass.edu>
Date: Tue, 17 Apr 90 18:41 EST
From: BROLIO@cs.umass.EDU
Subject: En/Decryption code?
To: common-lisp@mcc.COM
X-Vms-To: IN%"common-lisp@mcc.com"
Does anyone know of a Lisp DES private-key encryption/decryption
implementation?
John Brolio
Brolio@cs.umass.edu
∂26-Apr-90 1123 Common-Lisp-mailer multiple-value-list
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 26 Apr 90 11:23:29 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Thu 26 Apr 90 13:05:36-CDT
Received: from venera.isi.edu by SAIL.Stanford.EDU with TCP; 26 Apr 90 11:04:18 PDT
Received: from hpai23.isi.edu by venera.isi.edu (5.61/5.61+local)
id <AA19655>; Thu, 26 Apr 90 11:05:10 -0700
Posted-Date: Thu, 26 Apr 90 13:06:08 EST
Message-Id: <9004261806.AA12864@hpai23>
Received: by hpai23 (14.5/4.0.3-3)
id AA12864; Thu, 26 Apr 90 13:06:12 est
To: common-lisp@sail.stanford.edu
Subject: multiple-value-list
Cc: goldman@hpai23.isi.edu
Date: Thu, 26 Apr 90 13:06:08 EST
From: Neil Goldman <goldman@venera.isi.edu>
Is the list result of MULTIPLE-VALUE-LIST allowed to share structure
with a list used to supply the multiple values?
PRODUCER produces multiple values with VALUES-LIST. MULTIPLE-VALUE-NCONC
receives those values with MULTIPLE-VALUE-LIST and smashes the result.
In at least one commercial CL implementation,
(progn (multiple-value-nconc) *the-list*)
==> (1 2 3 4)
when PRODUCER is compiled.
----------------------------------------------------------------
(defun multiple-value-nconc ()
(nconc (multiple-value-list (producer)) (list 4)))
(defvar *the-list* nil)
(defun producer () (values-list (setf *the-list* (list 1 2 3))))
----------------------------------------------------------------
I believe that MULTIPLE-VALUE-LIST, like LIST, should be guaranteed
to produce unshared list structure. The reason is that when writing
MULTIPLE-VALUE-LIST I don't in general know, or have control of,
the code that will produce the multiple values. If I want to smash
the result in that situation, I must copy the list, although that
would generally be unnecessary (ALWAYS in some implementations of CL.)
On the other hand, I imagine that the lisp implementation could
avoid unnecessary copying in cases where the values were produces
by (VALUES ...) rather than (VALUES-LIST ...) or (APPLY #'VALUES ...).
(On the other hand, the implementation would have to copy the
list in some cases where structure sharing would in fact be safe.)
Implicit in my argument is an assumption that MULTIPLE-VALUE-LIST
is never REQUIRED to yield a list that shares structure with some
list used to produce the value, so no programmer (in portable code)
could take advantage of sharing.
Another way to look at this is that MULTIPLE-VALUE-LIST should be
allowed/required to yield a list that shares structure with a
list used to produce multiple values iff V would share list
structure with a list used to produce multiple values, in:
(multiple-value-call #'(lambda (&rest V) ...) (producer))
which, in turn, seems to be totally analogous to the passing
of list parameters via APPLY that might become bound to &rest
formals. Is there a concensus yet on the semantics of &rest
parameters, or has the specific issue of multiple-values and
list sharing been addressed?
(Incidentally, the commercial CL I tested which shared list
structure in the MULTIPLE-VALUE-LIST/VALUES-LIST communication
caused an ERROR in the MULTIPLE-VALUE-CALL example, both compiled
and interpreted!!)
∂13-May-90 2305 Common-Lisp-mailer Series & Generator Implemetation Wanted
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 13 May 90 23:04:54 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Mon 14 May 90 00:58:34-CDT
Received: from andrew.cmu.edu by SAIL.Stanford.EDU with TCP; 13 May 90 22:57:21 PDT
Received: by andrew.cmu.edu (5.54/3.15) id <AA05307> for common-lisp@sail.stanford.edu; Mon, 14 May 90 01:59:45 EDT
Received: via switchmail; Mon, 14 May 90 01:59:43 -0400 (EDT)
Received: from unix9.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/q003/QF.4aHYW3O00WB:40Pm9G>;
Mon, 14 May 90 01:56:20 -0400 (EDT)
Received: from unix9.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr25/js7a/.Outgoing/QF.8aHYW1200WB:Mm5xIT>;
Mon, 14 May 90 01:56:17 -0400 (EDT)
Received: from VUI.Andrew.3.70.CUILIB.3.45.SNAP.NOT.LINKED.unix9.andrew.cmu.edu.vax.3
via MS.5.6.unix9.andrew.cmu.edu.vax_3;
Mon, 14 May 90 01:56:16 -0400 (EDT)
Message-Id: <gaHYW0u00WB_Im5xAj@andrew.cmu.edu>
Date: Mon, 14 May 90 01:56:16 -0400 (EDT)
From: James Price Salsman <js7a+@andrew.cmu.edu>
To: common-lisp@sail.stanford.edu
Subject: Series & Generator Implemetation Wanted
Cc:
I'd like to experiment with the Series and Generator
features described in appendices A & B of CLtL 2ed.
Where can I get the implimentation? If it isn't ftpable
would someone please mail it to me? Thanks.
:jps
∂14-May-90 1214 Common-Lisp-mailer Re: Series & Generator Implemetation Wanted
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 14 May 90 12:13:54 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Mon 14 May 90 13:54:27-CDT
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 May 90 11:53:12 PDT
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA08937; Mon, 14 May 90 11:53:19 PDT
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA05927; Mon, 14 May 90 11:51:43 PDT
Received: by clam.sun.com (4.1/SMI-4.1)
id AA01941; Mon, 14 May 90 11:51:36 PDT
Date: Mon, 14 May 90 11:51:36 PDT
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <9005141851.AA01941@clam.sun.com>
To: common-lisp@sail.stanford.edu, js7a+@andrew.cmu.edu
Subject: Re: Series & Generator Implemetation Wanted
> I'd like to experiment with the Series and Generator
> features described in appendices A & B of CLtL 2ed.
>
> Where can I get the implimentation? If it isn't ftpable
> would someone please mail it to me? Thanks.
>
> :jps
Sending email to dick@wheaties.ai.mit.edu (Dick Waters) should certainly do
the job. You should be able to FTP it, too. It seems to be
under /pub/series on ai.ai.mit.edu, available for anonymous ftp.
-Cris
∂15-May-90 1128 Common-Lisp-mailer mailing list addition
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 May 90 11:28:04 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 15 May 90 13:20:52-CDT
Received: from natc-fw.navy.mil by SAIL.Stanford.EDU with TCP; 15 May 90 11:19:34 PDT
Date: 15 May 90 14:12:00 EDT
From: "CTL::GATEWOOD" <gatewood%ctl.decnet@natc-fw.navy.mil>
Subject: mailing list addition
To: "common-lisp" <common-lisp@sail.stanford.edu>
Please add me to your Common Lisp mailing list. Thanks.
gatewood%ctl.decnet@natc-fw.navy.mil
∂15-May-90 1333 Common-Lisp-mailer possible bug in READ-FROM-STRING
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 May 90 13:33:52 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 15 May 90 15:30:18-CDT
Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 15 May 90 13:29:02 PDT
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa08107; 15 May 90 20:45 BST
Date: Tue, 15 May 90 16:38:05 BST
Message-Id: <5131.9005151538@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: possible bug in READ-FROM-STRING
To: common-lisp@sail.stanford.edu
Cc: jkk%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK
One of my colleagues noticed some peculiar behavior in READ-FROM-STRING:
(read-from-string "* local wind speed" :start N)
returns: *
2
apparently no matter what the value of N is (I tried 2, 6 and 9).
We have tried this sort of thing in 5 different Common Lisps, and
all of them behave this way. Is it in fact the right behavior, or
is it a bug? (It's a bug on my reading of CLtLs I and II, but maybe
I'm missing something.)
-- Jeff
∂15-May-90 1352 Common-Lisp-mailer possible bug in READ-FROM-STRING
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 May 90 13:52:01 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 15 May 90 15:43:46-CDT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 May 90 13:42:32 PDT
Received: from hardwick ([192.31.212.104]) by heavens-gate.lucid.com id AA12338g; Tue, 15 May 90 13:42:25 PDT
Received: by hardwick id AA02107g; Tue, 15 May 90 13:43:13 PDT
Date: Tue, 15 May 90 13:43:13 PDT
From: Frank Yellin <fy%hardwick@lucid.com>
Message-Id: <9005152043.AA02107@hardwick>
To: jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK
Cc: common-lisp@sail.stanford.edu, jkk%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK
Subject: possible bug in READ-FROM-STRING
> One of my colleagues noticed some peculiar behavior in READ-FROM-STRING:
> (read-from-string "* local wind speed" :start N)
> returns: *
> 2
> apparently no matter what the value of N is (I tried 2, 6 and 9).
The argument list for #'read-from-string is
(read-from-string string &optional eof-error-p eof-value
&key :start :end :preserving-whitespace)
You can't give a function keyword arguments unless you also give it all of
its optional arguments.
Your call to read-from-string was binding eof-error-p to :start and
eof-value to whatever value n you passed.
What you actually want is:
(read-from-string "* local wind speed" t nil :start 2)
> (read-from-string "* local wind speed" t nil :start 2)
LOCAL
8
>
Frank Yellin
Lucid, Inc.
∂15-May-90 1412 Common-Lisp-mailer Re: possible bug in READ-FROM-STRING
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 May 90 14:12:18 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 15 May 90 15:55:17-CDT
Received: from SKEF.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 15 May 90 13:53:59 PDT
Received: from skef.slisp.cs.cmu.edu by SKEF.SLISP.CS.CMU.EDU id aa06208;
15 May 90 16:53:50 EDT
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
cc: common-lisp@sail.stanford.edu
Subject: Re: possible bug in READ-FROM-STRING
In-reply-to: Your message of Tue, 15 May 90 16:38:05 -0000.
<5131.9005151538@subnode.aiai.ed.ac.uk>
Date: Tue, 15 May 90 16:53:30 EDT
From: Skef.Wholey@SKEF.SLISP.CS.CMU.EDU
Date: Tue, 15 May 90 16:38:05 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: possible bug in READ-FROM-STRING
(read-from-string "* local wind speed" :start N)
returns: *
2
apparently no matter what the value of N is (I tried 2, 6 and 9).
Ha, this had me diving into the sources, first out of idle curiousity,
then in deepening confusion, until I looked at the DEFUN for
READ-FROM-STRING:
(defun read-from-string (string &optional eof-error-p eof-value
&key (start 0) (end (length string))
preserve-whitespace)
...)
Your :START and N are being taken as the EOF-ERROR-P and EOF-VALUE,
respectively. Ho ha. This kind of thing can only happen with functions
that have an even number of optionals between the required and keyword
args. Bad luck, totally, fer sure.
--Skef
∂15-May-90 1437 Common-Lisp-mailer possible bug in READ-FROM-STRING
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 May 90 14:37:51 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 15 May 90 16:21:13-CDT
Received: from mail.think.com by SAIL.Stanford.EDU with TCP; 15 May 90 14:15:25 PDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by mail.think.com; Tue, 15 May 90 17:15:42 -0400
Date: Tue, 15 May 90 17:15 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: possible bug in READ-FROM-STRING
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Cc: common-lisp@sail.stanford.edu, jkk%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK
In-Reply-To: <5131.9005151538@subnode.aiai.ed.ac.uk>
Message-Id: <19900515211538.0.BARMAR@OCCAM.THINK.COM>
Date: Tue, 15 May 90 16:38:05 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
One of my colleagues noticed some peculiar behavior in READ-FROM-STRING:
(read-from-string "* local wind speed" :start N)
returns: *
2
apparently no matter what the value of N is (I tried 2, 6 and 9).
We have tried this sort of thing in 5 different Common Lisps, and
all of them behave this way. Is it in fact the right behavior, or
is it a bug? (It's a bug on my reading of CLtLs I and II, but maybe
I'm missing something.)
-- Jeff
Oldest "bug" in the book. READ-FROM-STRING takes two optional arguments
before the keyword arguments. The above call specifies EOF-ERRORP =
:START and EOF-VALUE = N. The correct call is
(read-from-string "* local wind speed" t nil :start N)
Guy, you should have put a note in CLtL2 about this, considering how
many people get confused by it. It's probably the only frequently-used
function (maybe the only standard function at all) with both optional
and keyword arguments, and in this case the keyword options are much
more interesting than the optional ones.
barmar
∂15-May-90 1451 Common-Lisp-mailer possible bug in READ-FROM-STRING
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 May 90 14:51:51 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 15 May 90 16:31:59-CDT
Received: from mail.think.com by SAIL.Stanford.EDU with TCP; 15 May 90 14:30:44 PDT
Return-Path: <dan@Think.COM>
Received: from Nugodot.Think.COM by mail.think.com; Tue, 15 May 90 17:31:16 -0400
Received: by nugodot.think.com (4.0/Think-1.0C)
id AA14664; Tue, 15 May 90 17:31:09 EDT
Date: Tue, 15 May 90 17:31:09 EDT
From: dan@Think.COM
Message-Id: <9005152131.AA14664@nugodot.think.com>
To: Skef.Wholey@SKEF.SLISP.CS.CMU.EDU
Cc: jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK,
common-lisp@sail.stanford.edu
In-Reply-To: Skef.Wholey@SKEF.SLISP.CS.CMU.EDU's message of Tue, 15 May 90 16:53:30 EDT <9005152113.AA06019@gateway.think.com>
Subject: possible bug in READ-FROM-STRING
Date: Tue, 15 May 90 16:53:30 EDT
From: Skef.Wholey@SKEF.SLISP.CS.CMU.EDU
Date: Tue, 15 May 90 16:38:05 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
Subject: possible bug in READ-FROM-STRING
(read-from-string "* local wind speed" :start N)
returns: *
2
apparently no matter what the value of N is (I tried 2, 6 and 9).
Ha, this had me diving into the sources, first out of idle curiousity,
then in deepening confusion, until I looked at the DEFUN for
READ-FROM-STRING:
(defun read-from-string (string &optional eof-error-p eof-value
&key (start 0) (end (length string))
preserve-whitespace)
...)
Your :START and N are being taken as the EOF-ERROR-P and EOF-VALUE,
respectively. Ho ha. This kind of thing can only happen with functions
that have an even number of optionals between the required and keyword
args. Bad luck, totally, fer sure.
--Skef
Incidentally, you shouldn't feel bad. I know of a whole slew of people
(including myself) who has been bitten by this one.
--Dan
∂15-May-90 1517 Common-Lisp-mailer possible bug in READ-FROM-STRING
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 15 May 90 15:14:40 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 15 May 90 16:43:02-CDT
Received: from mail.think.com by SAIL.Stanford.EDU with TCP; 15 May 90 14:41:39 PDT
Return-Path: <gls@Think.COM>
Received: from Verdi.Think.COM by mail.think.com; Tue, 15 May 90 17:42:01 -0400
Received: by verdi.think.com; Tue, 15 May 90 17:42:00 EDT
Date: Tue, 15 May 90 17:42:00 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <9005152142.AA13780@verdi.think.com>
To: barmar@Think.COM
Cc: jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK,
common-lisp@sail.stanford.edu,
jkk%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK
In-Reply-To: Barry Margolin's message of Tue, 15 May 90 17:15 EDT <19900515211538.0.BARMAR@OCCAM.THINK.COM>
Subject: possible bug in READ-FROM-STRING
Date: Tue, 15 May 90 17:15 EDT
From: Barry Margolin <barmar@Think.COM>
Date: Tue, 15 May 90 16:38:05 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK>
One of my colleagues noticed some peculiar behavior in READ-FROM-STRING:
(read-from-string "* local wind speed" :start N)
returns: *
2
apparently no matter what the value of N is (I tried 2, 6 and 9).
We have tried this sort of thing in 5 different Common Lisps, and
all of them behave this way. Is it in fact the right behavior, or
is it a bug? (It's a bug on my reading of CLtLs I and II, but maybe
I'm missing something.)
-- Jeff
Oldest "bug" in the book. READ-FROM-STRING takes two optional arguments
before the keyword arguments. The above call specifies EOF-ERRORP =
:START and EOF-VALUE = N. The correct call is
(read-from-string "* local wind speed" t nil :start N)
Guy, you should have put a note in CLtL2 about this, considering how
many people get confused by it. It's probably the only frequently-used
function (maybe the only standard function at all) with both optional
and keyword arguments, and in this case the keyword options are much
more interesting than the optional ones.
barmar
I'll add this to be list of errata, even though it is technically
not a bug in the book.
∂16-May-90 1038 Common-Lisp-mailer CLtL Acronym Proposal
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 16 May 90 10:38:33 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 16 May 90 11:34:54-CDT
Received: from mail.think.com by SAIL.Stanford.EDU with TCP; 16 May 90 08:15:10 PDT
Return-Path: <traveler@Think.COM>
Received: from Regin.Think.COM by mail.think.com; Wed, 16 May 90 11:16:01 -0400
Received: by regin.think.com (4.0/Think-1.0C)
id AA25603; Wed, 16 May 90 11:11:38 EDT
Date: Wed, 16 May 90 11:11:38 EDT
Message-Id: <9005161511.AA25603@regin.think.com>
From: William R. Swanson <traveler@Think.COM>
Sender: traveler@Think.COM
To: common-lisp@sail.stanford.edu, slug@Warbucks.AI.SRI.COM, gls@Think.COM
Subject: CLtL Acronym Proposal
We have tried this sort of thing in 5 different Common Lisps, and
all of them behave this way. Is it in fact the right behavior, or
is it a bug? (It's a bug on my reading of CLtLs I and II, but maybe
I'm missing something.)
-- Jeff
A consensus is needed on the proper abbreviation for the old and
new editions of CLtL. So far I have seen the above example,
as well as CLtL vs. CLtL2. Therefore, in much the same spirit
as the naming convention of a certain computer manufacturer,
I propose the following "standard" abbreviations for these
and related documents, as well as a few for some possible
future publications:
CLtL => The "Silver Bible"
"Fat CLtL" => CLtL with email-circulated Errata sheet
CLtL Plus => CLtL plus Common Lisp, the Index
CLtL SE => The Second Edition
CLtL SE/30 => The Second Edition when/if Series and Generators are accepted
CLtL II => The next book, documenting the new ANSI standard for Common Lisp
CLtL IIx => The Hypercard stack that will be continually updated
for each succeeding revision of the standard
CLtL IIcx => The telememic transference system that will give
purchasers instant wizard-level experience with
the standard _as_it_happens_
CLtL IIIntx => I don't know what this will be, and neither does anyone else.
(Aren't you just quivering in anticipation?)
And of course, there will always be the ever popular
CLtL Portable => Your own personal scrapbook of information
copied from the above
"The Traveller" \ | /
________William R. Swanson________\|/_
Traveler @ Think.COM /|\
(617) 876-1111 x2065 / | \
∂22-May-90 1831 Common-Lisp-mailer lexical setf methods
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 22 May 90 18:31:38 PDT
Received: from venera.isi.edu by MCC.COM with TCP/SMTP; Tue 22 May 90 20:19:38-CDT
Received: from hpai23.isi.edu by venera.isi.edu (5.61/5.61+local)
id <AA09146>; Tue, 22 May 90 18:19:39 -0700
Posted-Date: Tue, 22 May 90 21:19:24 EDT
Message-Id: <9005230119.AA24647@hpai23>
Received: by hpai23 (14.5/4.0.3-3)
id AA24647; Tue, 22 May 90 21:19:28 edt
To: common-lisp@mcc.com
From: goldman@ISI.EDU
Subject: lexical setf methods
Date: Tue, 22 May 90 21:19:24 EDT
Sender: goldman@venera.isi.edu
How can I define a lexically scoped setf method to go along with
a lexical function/macro? (I am talking about setf methods in the
sense of define-setf-method, not CLOS methods). Is something like the
following supposed to be legal?
(macrolet ((m (a b) ...)
((setf m) (a b &environment e) (values <the holy 5>)))
...
(setf (m x y) 3)
...)
[I notice that DEFINE-SETF-METHOD is stated to be a MACRO, not a
SPECIAL-FORM. Does that mean there is a portable alternative
to DEFINE-SETF-METHOD? If I knew what it was, maybe I could
figure out how to do what I want.]
neil
∂22-May-90 2033 Common-Lisp-mailer lexical setf methods
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 22 May 90 20:33:08 PDT
Received: from uunet.uu.net by MCC.COM with TCP/SMTP; Tue 22 May 90 22:18:47-CDT
Received: by uunet.uu.net (5.61/1.14) with UUCP
id AA14155; Tue, 22 May 90 23:18:40 -0400
Received: by franz.Franz.COM (MC 2.0/FI-1.0)
id AA00707; Tue, 22 May 90 21:11:09 PDT
Received: by fiona.Franz.COM (4.0/FI-1.0)
id AA01424; Tue, 22 May 90 20:08:34 PDT
Date: Tue, 22 May 90 20:08:34 PDT
From: smh@Franz.COM (Steve Haflich)
Message-Id: <9005230308.AA01424@fiona.Franz.COM>
To: goldman@ISI.EDU
Cc: common-lisp@mcc.com
In-Reply-To: goldman@ISI.EDU's message of Tue, 22 May 90 21:19:24 EDT <9005230119.AA24647@hpai23>
Subject: lexical setf methods
From: goldman@ISI.EDU
How can I define a lexically scoped setf method to go along with
a lexical function/macro? (I am talking about setf methods in the
sense of define-setf-method, not CLOS methods). Is something like the
following supposed to be legal?
(macrolet ((m (a b) ...)
((setf m) (a b &environment e) (values <the holy 5>)))
...
(setf (m x y) 3)
...)
X3J13 Common Lisp does support lexically-scoped setf methods, but only
for "setf functions," not for setf macros. (See CLtL2 p.128.) In
other words, you need to define a lexical _function_ with the name
(setf m) instead of a macro. Your macrolet is not legal because macro
names are still required to be symbols.
Flet is sufficient to establish such a lexical setf function. Here is
an example:
<cl> (defvar *foo*)
*foo*
<cl> (flet (((setf m) (val) (setq *foo* val)))
(setf (m) 123))
123
<cl> *foo*
123
But before you get too excited, remember that setf functions are new
and not supported by most of the CL implementations in current
distribution. I ran the above example in our not-yet-available 4.0
product -- it would not have worked in the current 3.1 release.
If your local lisp implementation doesn't support setf functions it
may be possible to kludge something together, but it would be real
ugly. You could advise the SETF macro with an error condition handler
that returns a form that calls the setting function named by the
symbol (INTERN (FORMAT NIL "(SETF ~S)" (CADR FORM))), and then a FLET
of the function name |(SETF M)| would do the right thing. PCL did
some similar naming hacks for setter functions.
∂22-May-90 2235 Common-Lisp-mailer lexical setf methods
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 22 May 90 22:35:49 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Wed 23 May 90 00:17:29-CDT
Return-Path: <barmar@Think.COM>
Received: from Nugodot.Think.COM by mail.think.com; Wed, 23 May 90 01:17:24 -0400
Received: by nugodot.think.com (4.0/Think-1.0C)
id AA11692; Wed, 23 May 90 01:17:17 EDT
Date: Wed, 23 May 90 01:17:17 EDT
From: barmar@Think.COM
Message-Id: <9005230517.AA11692@nugodot.think.com>
To: goldman@ISI.EDU
Cc: common-lisp@mcc.com
In-Reply-To: <9005230119.AA24647@hpai23>
Subject: lexical setf methods
From: goldman@ISI.EDU
Date: Tue, 22 May 90 21:19:24 EDT
How can I define a lexically scoped setf method to go along with
a lexical function/macro? (I am talking about setf methods in the
sense of define-setf-method, not CLOS methods). Is something like the
following supposed to be legal?
(macrolet ((m (a b) ...)
((setf m) (a b &environment e) (values <the holy 5>)))
...
(setf (m x y) 3)
...)
In ANSI CL you'll be able to define lexical setf functions by defining a
lexical function named (SETF M). This is an X3J13 addition to the
language, so CLtL-conformant Lisps won't necessarily have it. I don't
think you can define lexical macro-style setf *methods*, except for the automatic ones
available because setf macroexpands its odd subforms.
[I notice that DEFINE-SETF-METHOD is stated to be a MACRO, not a
SPECIAL-FORM. Does that mean there is a portable alternative
to DEFINE-SETF-METHOD? If I knew what it was, maybe I could
figure out how to do what I want.]
It's a macro that expands into implementation-dependent code.
∂05-Jun-90 1349 Common-Lisp-mailer CLOS Report Project: Status and more Contribution Opportunities
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 5 Jun 90 13:49:46 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 5 Jun 90 15:05:24-CDT
Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 5 Jun 90 13:03:54 PDT
Received: from hplap.hpl.hp.com by hplms2.hpl.hp.com with SMTP
(15.11.1.3/15.5+IOS 3.20) id AA03459; Tue, 5 Jun 90 13:05:29 pdt
Received: from localhost by hplap.hpl.hp.com with SMTP
(15.11/15.5+IOS 3.14) id AA02015; Tue, 5 Jun 90 13:04:53 pdt
Message-Id: <9006052004.AA02015@hplap.hpl.hp.com>
To: commonloops.pa@xerox.com, common-lisp-object-system@sail.stanford.edu,
common-lisp@sail.stanford.edu
Subject: CLOS Report Project: Status and more Contribution Opportunities
X-Mailer: mh6.5
Date: Tue, 05 Jun 90 13:04:52 PDT
From: Andreas Paepcke <paepcke@hplap.hpl.hp.com>
Some weeks back I mailed out the call for papers for our CLOS Report
publication. That original call is attached again for convenience. The
purpose of this message is to let people know about the status of the
project and to encourage further potential contributors.
We now have a very nice spread of projected contributions, covering most
areas in the Call for Papers: the introductory material at this point
contains an intellectual history of the language, a short introduction to
CLOS features and an introduction to the MOP. The relationship of CLOS to
other languages is covered so far with a comparison of CLOS and Eiffel, the
analysis of some CLOS aspects in light of the notion of type in ML and the
use of the MOP in the context of Smalltalk, as compared to CLOS. Some
papers will try to show how the MOP idea - as exemplified in the definition
and implementation of CLOS - can have a broader impact. Other papers
include thoughts about CLOS style/usage, various applications and,
possibly, a paper on the design rationale of CLOS. This will try to recall
some of the important design decisions that were made in the past.
Several of the sections above can obviously be expanded and thereby provide
an opportunity for contribution. Comparisons with other languages and
applications which use CLOS are examples. Papers on applications should, of
course, emphasize CLOS, rather than the application.
Apart from papers, I would be interested to hear input on which past design
issues/motivations/gotchas should be included in a rationale paper. The
idea is to avoid losing lessons learned during the development of CLOS and
its implementation.
Deadline for papers is to be October 1. Recall that the audience is
intended to be broad. The Report will be a single source for people
interested in learning about CLOS and its issues on various levels of
sophistication. This is the reason for the spread from introductory to
theoretical papers.
If you plan to contribute, please drop me a couple of lines to help me
continue with my planning. An extended abstract would be an excellent entry
to the CLOS Workshop in the Fall at OOPSLA (deadline Aug 1). The Call for
Papers for that went out a couple of weeks ago. Submission and attendance
at the Workshop is, however, not a prerequisite for participation in the
CLOS Report project.
Hoping to hear from you,
Andreas
;;;;;;;;;;;;;;;;;;;;; Original Call for Papers for CLOS Report ;;;;;;;;;;;;;;;;;;;;;
Call for contribution: A "CLOS Report" Publication
--------------------------------------------------
With the standardization of chapters 1 and 2 done and people slaving away
at building applications, I feel it is time to make CLOS more accessible to
people with various degrees of interest. I am therefore soliciting your
help in working towards a publication to accomplish this.
I have in mind a collection of papers by members of the CLOS community,
which would be published in a place where it is easiliy available to a
broad audience. This serves the purpose both of popularizing CLOS and of
ensuring recognition for the contributors.
The appendix of this message contains a draft of the collection's
categorization. I am now looking for participation and/or suggestions to
get this project off the ground. Examples:
* Does the categorization make sense?
* Do you recommend an existing paper to be
reprinted in the collection?
* Would you like to contribute a new paper?
* Do you know of someone else who might be able to
contribute?
* Can you volunteer to help with the editing process?
If you can produce a paper, I would very much like to hear from you
informally soon. It is enough to explain which category you want to address
and very roughly what you have in mind. This will make planning a lot
easier because it will help me decide which contributions I must actively
reach out for to get coverage. Please help me gather some of this data.
As a separate project, I am organizing this year's CLOS Users and
Implementors Workshop to be held in the context of OOPSLA '90. I will send
out the call for participation as soon as the OOPSLA administration gives a
green light. This should be by May 28. Even though the Workshop is separate
from the publication described here, there will be linkage in that work
done for the Workshop can find its way into the publication.
Hoping to hear from you soon,
Andreas
Hewlett-Packard Laboratory
Palo Alto, Ca 94304
paepcke@hplabs.hp.com
415-857-7398
;;;;;;;;;;;;;;;;;;;; Categorization Draft ;;;;;;;;;;;;;;;;;;;;;;;;;
%-----------------------------------------------------
% Summary Categorization of Papers
%---------------------------------
Prologue: What is it like to build a language?
Short introduction to CLOS
Applications
Contrasting CLOS with other languages
CLOS Analysis and Discussion
CLOS implementations
Open research issues
Glossary
Annotated Bibliography
Index over all papers
Author Index
Prologue: What is it like to build a language?
----------------------------------------------
Audience: General, not necessarily CLOS or even language-oriented.
Example contents:
- How were existing languages used as blueprints?
- How was the design effort organized?
- Comments on PCL's implementation and distribution.
- Honestly: Was CLOS designed top-down, bottom-up, upside-down,
inside-out or without any of the fashionable CASE disciplines?
- How did the standardization process work? Any advice for others who
want to standardize something?
Short introduction to CLOS:
---------------------------
Very top level, a few pages that make a casual reader aware of what CLOS is
about. If someone has heard the term "CLOS" a lot and wants to know what it
is, this should be the place to go to.
Example contents:
- The five CLOS building blocks.
- A few programming examples.
- Maybe the architecture (MOP concept).
- References to more in-depth sources.
Applications:
-------------
Contributions in this category should go into some depth. While some parts
could be accessible to a casually browsing audience, other parts of the
contributions should satisfy a more serious reader who is considering the
use of CLOS for her own purposes.
Example contents:
- What does the application do?
- Why was CLOS chosen as the implementation language in the first place?
- Where did CLOS shine for the application, where did it weaken or fail?
There might be a discussion of how other languages would have worked
out for this particular application.
- How did the language affect the application design?
- How is the application delivered? (ex: Is there a small CLOS delivery
kernel?)
Contrasting CLOS with other languages:
--------------------------------------
Contributions may be arbitrarily complex and specialized, although it would
be good to have one or two papers accessible to an interested computer
scientist who knows some other object-oriented language and wants an easy
way of finding the correct mental pigeon hole for CLOS.
It would be nice if contributions were dialectic. Maybe two or more authors
with violently different opinions could get together and produce one
sharp-edged discussion.
Example contents:
- Strong and weak points of CLOS vs. other languages.
- Classification of languages along a particular theme (ex: realization
of functional programming, extensibility, oop philosophy,
speed/functionality tradeoffs, etc.)
- Classification of applications by which languages would be optimal for
their realizations.
CLOS Analysis and Discussion:
-----------------------------
This is for very CLOS-specific contributions. Like papers in the "language
contrasting" category, possibly combative, but *technical* pro/con flames
combined into one paper would be interesting if they help to focus a
reader's attention on some CLOS aspect.
Example contents:
- Was the MOP a good idea?
- Is the MOP-level class hierarchy sensible?
- What were the CLOS architectural tradeoffs? Why were particular
alternatives chosen?
- Which tradeoffs were resolved to CLOS' detriment.
CLOS implementations:
---------------------
This is to be a non-commercial category. Papers may point out
implementation issues, even if the author(s) have not produced any
implementation themselves.
Example contents:
- Which parts of CLOS are easy to implement, which are hard?
- Are there clever optimization opportunities?
- Are there language aspects that should have been defined differently,
given the experience gained from an actual implemention process.
Open research issues:
---------------------
The audience for papers in this category would be a competent computer
scientist looking for something to do.
Example contents:
- Anything
Glossary:
---------
Short definitions of CLOS terms.
Annotated Bibliography:
-----------------------
This is to cover the range from casual interest to very specific CLOS
issues. It would be nice if this could be a union of the bibliographies
of the papers.
Index
-----
Terms, concepts, etc. covering all the papers.
Author Index
------------
∂06-Jun-90 1726 Common-Lisp-mailer NULL(tm)
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 6 Jun 90 17:25:51 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Wed 6 Jun 90 19:06:07-CDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by mail.think.com; Wed, 6 Jun 90 20:06:01 -0400
Date: Wed, 6 Jun 90 20:05 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: NULL(tm)
To: common-lisp@mcc.com
Message-Id: <19900607000554.4.BARMAR@OCCAM.THINK.COM>
Seen in netnews:
Path: think!snorkelwacker!apple!usc!cs.utexas.edu!uunet!jarthur!mti!adrian
From: adrian@mti.mti.com (Adrian McCarthy)
Newsgroups: comp.lang.c
Subject: NULL(tm)
Message-ID: <1043@mti.mti.com>
Date: 6 Jun 90 19:11:38 GMT
Reply-To: adrian@mti.UUCP (Adrian McCarthy)
Organization: Micro Technology, Anaheim, CA
Mattel has a new line of action figures called Computer Warriors(tm). It
turns out that one of the bad guys is called NULL (yes, all caps). To top
it off, NULL is a trademark of Mattel Corp. So I guess we'll all have to
edit our stdio.h files to read:
#define NULL /* trademark of Mattel Corp. :-) */ 0
Aid. (adrian@gonzo.mti.com)
While Common Lisp doesn't have this problem with the null pointer, we do
have the data type NULL. I guess we'll have to edit our programs to use
(check-type <place> (or null ;; (TM) Mattel Corp.
<types...>)
∂07-Jun-90 0618 Common-Lisp-mailer Re: NULL(tm)
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 7 Jun 90 06:18:41 PDT
Received: from primost.cs.wisc.edu by MCC.COM with TCP/SMTP; Thu 7 Jun 90 07:58:29-CDT
Message-Id: <9006071258.AA02493@primost.cs.wisc.edu>
Received: from localhost by primost.cs.wisc.edu; Thu, 7 Jun 90 07:58:12 -0500
To: Barry Margolin <barmar@think.com>
Cc: common-lisp@mcc.com
Subject: Re: NULL(tm)
In-Reply-To: Your message of Wed, 06 Jun 90 20:05:00 EDT.
<19900607000554.4.BARMAR@OCCAM.THINK.COM>
Reply-To: larus@cs.wisc.edu
Date: Thu, 07 Jun 90 07:58:10 CDT
From: James Larus <larus@cs.wisc.edu>
Seems like this is a good time to reevaluate Common Lisp's
questionable decision about folding symbols to uppercase.
/Jim
∂16-Jul-90 1442 Common-Lisp-mailer read-delimited-list
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 16 Jul 90 14:42:41 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Mon 16 Jul 90 15:58:58-CDT
Return-Path: <barmar@Think.COM>
Received: from Occam.Think.COM by mail.think.com; Mon, 16 Jul 90 16:57:58 -0400
Date: Mon, 16 Jul 90 16:57 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: read-delimited-list
To: Len Charest <Charest@AI-SUN.jpl.nasa.gov>
Cc: slug@Warbucks.AI.SRI.COM, common-lisp@mcc.com
In-Reply-To: <19900716171439.1.CHAREST@AI-ARIEL.jpl.nasa.gov>
Message-Id: <19900716205746.9.BARMAR@OCCAM.THINK.COM>
Date: Mon, 16 Jul 90 10:14 PDT
From: Charest@AI-SUN.jpl.nasa.gov (Len Charest)
The following example sets up a reader macro on the open bracket char
whose contract is to return a quoted list of the elements delimited by
the open bracket and the close bracket. Additionally, the keyword :FACT
is to be consed onto the front of the quoted list. (See CLtL 2ed, page
546 for a similar example).
(defun open-bracket-macro-char (stream macro-char)
(declare (ignore macro-char))
(let ((l (read-delimited-list #\] stream t)))
(values `(quote (:fact ,@l)))))
(set-macro-character #\[ #'open-bracket-macro-char)
(set-macro-character #\] (get-macro-character #\) ))
Then
(defvar zzz [foo bar baz])
should return
(:fact foo bar baz)
but instead I get an error in the reader because the close bracket
delimiter is not being properly recognized. If a whitespace char is inserted
before the last element, as in
(defvar zzz [foo bar baz ])
then all is well. But this is no "solution."
Is this an error in my code or in the implementation of read-delimited-list?
I don't think Symbolics implements the close parenthesis as a macro character
so (set-macro-character #\] (get-macro-character #\) )) is not doing anything
useful. If read-delimited-list is at fault, does anybody have a decent
workaround? Note well that I am still using Genera 7.2.
This is probably a bug, since CLtL clearly states that ")" is a macro
character, but (get-macro-character #\)) returns NIL in Genera (it fails
in 8.0 as well). However, it's easy to work around it in a portable
fashion. Instead of the (set-macro-character #\] ...), do
(set-syntax-from-char #\] #\)).
I'm cc'ing this to the common-lisp mailing list, as I think this should
be the recommended way to do this, and CLtL shouldn't be using
set-macro-character in its examples. In Lisps that implement ")" using
a private extension (which I think should be permitted) rather than as a
macro character the CLtL way won't work. However, set-syntax-from-char
is required to copy macro definitions, so it should work in both types
of implementations.
barmar
∂16-Jul-90 1501 Common-Lisp-mailer read-delimited-list
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 16 Jul 90 15:01:47 PDT
Received: from AI-SUN.jpl.nasa.gov by MCC.COM with TCP/SMTP; Mon 16 Jul 90 16:24:24-CDT
Received: from AI-ARIEL.jpl.nasa.gov by AI-SUN.jpl.nasa.gov via CHAOS with CHAOS-MAIL id 29933; Mon 16-Jul-90 14:19:15 PDT
Date: Mon, 16 Jul 90 14:19 PDT
From: Len Charest <Charest@AI-SUN.jpl.nasa.gov>
Subject: read-delimited-list
To: barmar@Think.COM, Charest@AI-SUN.jpl.nasa.gov
cc: slug@Warbucks.AI.SRI.COM, common-lisp@mcc.com
In-Reply-To: <19900716205746.9.BARMAR@OCCAM.THINK.COM>
Message-ID: <19900716211903.2.CHAREST@AI-ARIEL.jpl.nasa.gov>
Date: Mon, 16 Jul 90 10:14 PDT
From: Charest@AI-SUN.jpl.nasa.gov (Len Charest)
The following example sets up a reader macro on the open bracket char
whose contract is to return a quoted list of the elements delimited by
the open bracket and the close bracket. Additionally, the keyword :FACT
is to be consed onto the front of the quoted list. (See CLtL 2ed, page
546 for a similar example).
(defun open-bracket-macro-char (stream macro-char)
(declare (ignore macro-char))
(let ((l (read-delimited-list #\] stream t)))
(values `(quote (:fact ,@l)))))
(set-macro-character #\[ #'open-bracket-macro-char)
(set-macro-character #\] (get-macro-character #\) ))
Then
(defvar zzz [foo bar baz])
should return
(:fact foo bar baz)
but instead I get an error in the reader because the close bracket
delimiter is not being properly recognized. If a whitespace char is inserted
before the last element, as in
(defvar zzz [foo bar baz ])
then all is well. But this is no "solution."
Is this an error in my code or in the implementation of read-delimited-list?
I don't think Symbolics implements the close parenthesis as a macro character
so (set-macro-character #\] (get-macro-character #\) )) is not doing anything
useful. If read-delimited-list is at fault, does anybody have a decent
workaround? Note well that I am still using Genera 7.2.
This is probably a bug, since CLtL clearly states that ")" is a macro
character, but (get-macro-character #\)) returns NIL in Genera (it fails
in 8.0 as well). However, it's easy to work around it in a portable
fashion. Instead of the (set-macro-character #\] ...), do
(set-syntax-from-char #\] #\)).
I'm cc'ing this to the common-lisp mailing list, as I think this should
be the recommended way to do this, and CLtL shouldn't be using
set-macro-character in its examples. In Lisps that implement ")" using
a private extension (which I think should be permitted) rather than as a
macro character the CLtL way won't work. However, set-syntax-from-char
is required to copy macro definitions, so it should work in both types
of implementations.
I've come up with my own solution:
(defun close-brace-macro-char (stream macro-char)
(declare (ignore stream macro-char))
(values))
(set-macro-character #\} #'close-brace-macro-char)
so now read-delimited-list as used above does the right thing.
Len Charest
∂19-Jul-90 1702 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 19 Jul 90 17:02:27 PDT
Received: from atc.boeing.com by MCC.COM with TCP/SMTP; Thu 19 Jul 90 18:56:25-CDT
Received: by atc.boeing.com on Thu, 19 Jul 90 16:54:48 PDT
Date: Thu, 19 Jul 90 16:53 PDT
From: Stephen L. Nicoud <snicoud@atc.boeing.com>
Subject: DOTIMES
To: common-lisp@mcc.com
Message-Id: <19900719235328.5.SLN@SKAGIT.atc.boeing.com>
Given this function definition
(defun test ()
(dotimes (a 3)
(print :hello)))
Should/Must/Can a Common Lisp implementation warn of an unused variable
(a)?
What should be the behavior in this scenario:
(defun test ()
(dotimes (a 3)
(declare (ignore a))
(print :hello)))
Since implementations of DOTIMES expand to use the variable,
should/must/can a CL implementation warn of using a variable that was
declared ignored?
As you have probably guessed compiling these functions produces different
warnings in different implementations. Trying to suppress the warnings in
one results in the issuing of warnings in the other. I would hate to have
to sprinkle #+/-vendor-common-lisp everywhere I use DOTIMES in this
fashion.
What's the right way to use DOTIMES portably so that warnings are
not issued in the impending ANSI CL implementations? It would be
nice to know what ANSI CL will prescribe for this situation.
This probably begs the whole question of how much the user must know in
general about the expansion of any macro defined as part of ANSI Common
Lisp.
Steve
--
Stephen L. Nicoud <snicoud@atc.boeing.com> uw-beaver!bcsaic!snicoud
Boeing Advanced Technology Center for Computer Sciences
∂19-Jul-90 1853 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 19 Jul 90 18:53:01 PDT
Received: from lucid.com by MCC.COM with TCP/SMTP; Thu 19 Jul 90 20:50:50-CDT
Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA02783g; Thu, 19 Jul 90 18:47:38 PDT
Received: by ptl-club id AA08068g; Thu, 19 Jul 90 18:51:02 PDT
Date: Thu, 19 Jul 90 18:51:02 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <9007200151.AA08068@ptl-club>
To: snicoud@atc.boeing.com
Cc: common-lisp@mcc.com
In-Reply-To: Stephen L. Nicoud's message of Thu, 19 Jul 90 16:53 PDT <19900719235328.5.SLN@SKAGIT.atc.boeing.com>
Subject: DOTIMES
re: Given this function definition
(defun test ()
(dotimes (a 3)
(print :hello)))
Should/Must/Can a Common Lisp implementation warn of an unused
variable (a)?
Warning messages are a very stylistic matter, and aren't generally
mandated or prohibited by CLtL. The existence of an IGNORE declaration
*is* a standard (from CLtL); the issuance or quiescence of a warning based
on it is merely marked "desirable" -- not a standard. At any rate, it's
very unlikely that any non-compiling interpreter will warn you about this
case; so it's really a compiler interface issue, about which there are few
standards.
Now, in the realm of compilation, Lucid's compilers take one of the bits
of CLtL advice about when it is "desirable" to issue a warning, but not
all of the advices. Thus it will warn you if you bind-but-dont-use a local
variable (and don't declare-ignore on it); but it doesn't bother you with
warnings about variables declared IGNORE which are used anyway.
The effect of this selective approach to the admonitions is that declare
IGNORE means "Don't issue any UNUSED warning messages about this variable".
Indeed, this isn't in exact accord with the CLtL statement of it's meaning
"...specifies that the bindings ... are never used"; but then my little
summary here is an observation, not a definition. The reason I bother
to state this non-standard observation is that this seems to be the
most-often requested behaviour -- namely, users want to be generous with
IGNORE declarations in order to gag potential warnings, but don't want
to be WARN'd about the cases where that generosity went overboard.
-- JonL --
∂20-Jul-90 0722 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 20 Jul 90 07:22:26 PDT
Received: from SAPSUCKER.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Fri 20 Jul 90 09:07:21-CDT
Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 366820; 20 Jul 90 10:09:45 EDT
Date: Fri, 20 Jul 90 10:07 EDT
From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
Subject: DOTIMES
To: snicoud@atc.boeing.com, common-lisp@mcc.com
In-Reply-To: <19900719235328.5.SLN@SKAGIT.atc.boeing.com>
Message-ID: <19900720140701.8.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM>
Date: Thu, 19 Jul 90 16:53 PDT
From: Stephen L. Nicoud <snicoud@atc.boeing.com>
Given this function definition
(defun test ()
(dotimes (a 3)
(print :hello)))
Should/Must/Can a Common Lisp implementation warn of an unused variable
(a)?
A warning should probably be issued that A is unused, but that seems
optional. I suspect that opinions vary widely on this. Genera does
this, as of Release 8.
What should be the behavior in this scenario:
(defun test ()
(dotimes (a 3)
(declare (ignore a))
(print :hello)))
Since implementations of DOTIMES expand to use the variable,
should/must/can a CL implementation warn of using a variable that was
declared ignored?
A warning should definitely be issued when a variable is declared to be
ignored, but is used anyway.
As you have probably guessed compiling these functions produces different
warnings in different implementations. Trying to suppress the warnings in
one results in the issuing of warnings in the other. I would hate to have
to sprinkle #+/-vendor-common-lisp everywhere I use DOTIMES in this
fashion.
What's the right way to use DOTIMES portably so that warnings are
not issued in the impending ANSI CL implementations? It would be
nice to know what ANSI CL will prescribe for this situation.
This probably begs the whole question of how much the user must know in
general about the expansion of any macro defined as part of ANSI Common
Lisp.
Welcome to the world of portable programming!
∂20-Jul-90 0800 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 20 Jul 90 07:59:55 PDT
Received: from SAPSUCKER.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Fri 20 Jul 90 09:52:51-CDT
Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 366847; 20 Jul 90 10:54:59 EDT
Date: Fri, 20 Jul 90 10:52 EDT
From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
Subject: DOTIMES
To: SWM@SAPSUCKER.SCRC.Symbolics.COM, snicoud@atc.boeing.com, common-lisp@mcc.com
In-Reply-To: <19900720140701.8.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM>
Message-ID: <19900720145216.0.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM>
Date: Fri, 20 Jul 90 10:07 EDT
From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
Date: Thu, 19 Jul 90 16:53 PDT
From: Stephen L. Nicoud <snicoud@atc.boeing.com>
Given this function definition
(defun test ()
(dotimes (a 3)
(print :hello)))
Should/Must/Can a Common Lisp implementation warn of an unused variable
(a)?
A warning should probably be issued that A is unused, but that seems
optional. I suspect that opinions vary widely on this. Genera does
this, as of Release 8.
KMP, as it turns out, has a varying opinion, and points out that, with
the obvious expansion of DOTIMES, my two positions are contradictory.
However, I don't advocate the obvious expansion of DOTIMES (the one that
just uses A). Parts of the Lisp language should be "black boxes", that
is, if DOTIMES uses A itself, it should do so "invisibly".
KMP also points out that this is one distinction between special forms
and macros. Unfortunately, DOTIMES is specified as a macro rather than
as a special form.
The one thing that is certain is that ANSI CL needs to take a stand on
these issues.
What should be the behavior in this scenario:
(defun test ()
(dotimes (a 3)
(declare (ignore a))
(print :hello)))
Since implementations of DOTIMES expand to use the variable,
should/must/can a CL implementation warn of using a variable that was
declared ignored?
A warning should definitely be issued when a variable is declared to be
ignored, but is used anyway.
As you have probably guessed compiling these functions produces different
warnings in different implementations. Trying to suppress the warnings in
one results in the issuing of warnings in the other. I would hate to have
to sprinkle #+/-vendor-common-lisp everywhere I use DOTIMES in this
fashion.
What's the right way to use DOTIMES portably so that warnings are
not issued in the impending ANSI CL implementations? It would be
nice to know what ANSI CL will prescribe for this situation.
This probably begs the whole question of how much the user must know in
general about the expansion of any macro defined as part of ANSI Common
Lisp.
Welcome to the world of portable programming!
∂24-Jul-90 0525 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 05:25:47 PDT
Received: from NSFnet-Relay.AC.UK by MCC.COM with TCP/SMTP; Tue 24 Jul 90 07:14:46-CDT
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa12567; 23 Jul 90 23:19 BST
Date: Mon, 23 Jul 90 23:26:21 BST
Message-Id: <26237.9007232226@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: DOTIMES
To: Jon L White <jonl@lucid.com>, snicoud@atc.boeing.com
In-Reply-To: Jon L White's message of Thu, 19 Jul 90 18:51:02 PDT
Cc: common-lisp@mcc.com
> re: Given this function definition
> (defun test ()
> (dotimes (a 3)
> (print :hello)))
> Should/Must/Can a Common Lisp implementation warn of an unused
> variable (a)?
I'm inclined to say "no", because A is "used" to make the iteration
happen three times.
But here is one place where we're paying the price for not offering
an "as if" expansion of the standard macros (when possible). Compare
this to the Scheme standard and Revised Reports. (I know there are
good reasons for not specifying with code, but if you don't you may
have to specify more things explicitly.
> Warning messages are a very stylistic matter, and aren't generally
> mandated or prohibited by CLtL. The existence of an IGNORE declaration
> *is* a standard (from CLtL); the issuance or quiescence of a warning based
> on it is merely marked "desirable" -- not a standard. At any rate, it's
> very unlikely that any non-compiling interpreter will warn you about this
> case; so it's really a compiler interface issue, about which there are few
> standards.
If this is supposed to be an argument that the standard needn't
address this issue, then I disagree. IGNORE declarations are very
like ASSERTions; and they provide information to human readers as
well as to implementations. They aren't just to avoid warnings
by to assert something about the code.
Programmers ought to be able to write correct IGNORE declarations in
every case where a variable is not used and ought to be able to write
code in which every variable not subject to an IGNORE declaration *is*
used.
If Common Lisp doesn't define "use" enough for this to be possible,
then the definition should be improved or else we should admit
defeat and say IGNORE declarations are a compiler interface issue
and so should not be part of standard Common Lisp.
Another way to admit defeat would be to change the meaning of an
IGNORE declaration so that it says only that a variable *might not*
be used.
-- Jeff
∂24-Jul-90 0719 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 07:19:10 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Tue 24 Jul 90 09:12:38-CDT
Return-Path: <gls@Think.COM>
Received: from Verdi.Think.COM by mail.think.com; Tue, 24 Jul 90 10:12:03 -0400
Received: from mozart.think.com by verdi.think.com; Tue, 24 Jul 90 10:12:02 EDT
From: gls@Think.COM (Guy Steele)
Received: by mozart.think.com; Tue, 24 Jul 90 10:12:01 EDT
Date: Tue, 24 Jul 90 10:12:01 EDT
Message-Id: <9007241412.AA28081@mozart.think.com>
To: jeff@aiai.edinburgh.ac.uk
Cc: jonl@lucid.com, snicoud@atc.boeing.com, common-lisp@mcc.com
In-Reply-To: Jeff Dalton's message of Mon, 23 Jul 90 23:26:21 BST <26237.9007232226@subnode.aiai.ed.ac.uk>
Subject: DOTIMES
If in fact the only case of interest in this discussion
is using DOTIMES but ignoring the variable, then I think
this is a strong argument for putting a REPEAT macro
into the language.
(REPEAT n . body) == (LOOP REPEAT n DO . body)
or some such. Or just use LOOP. (Just that little bit
won't hurt you. Really.)
--Guy
∂24-Jul-90 0846 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 08:46:48 PDT
Received: from charon.MIT.EDU by MCC.COM with TCP/SMTP; Tue 24 Jul 90 10:35:36-CDT
Received: by charon.MIT.EDU
id AA14270; Tue, 24 Jul 90 11:35:06 EDT
Date: Tue, 24 Jul 90 11:35:06 EDT
From: kab@charon.MIT.EDU (Kim A. Barrett)
Message-Id: <9007241535.AA14270@charon.MIT.EDU>
To: jeff@aiai.edinburgh.ac.uk
Cc: jonl@lucid.com, snicoud@atc.boeing.com, common-lisp@mcc.com
In-Reply-To: Jeff Dalton's message of Mon, 23 Jul 90 23:26:21 BST <26237.9007232226@subnode.aiai.ed.ac.uk>
Subject: DOTIMES
>> re: Given this function definition
>> (defun test ()
>> (dotimes (a 3)
>> (print :hello)))
>> Should/Must/Can a Common Lisp implementation warn of an unused
>> variable (a)?
> I'm inclined to say "no", because A is "used" to make the iteration
> happen three times.
Actually, things aren't so simple. When you say that the variable is being
used to control the iteration, you are assuming a particular expansion, ie.
something like the following:
(defmacro dotimes ((var init &optional result) &body body)
(let ((end (gensym)))
`(do ((,var 0 (1+ ,var))
(,end (the integer ,init))) ; "should be integer"
((<= ,end ,var) ,result)
,@body)))
which, for the dotimes in the example function would expand into (with gensyms
named for readability):
(do ((a 0 (1+ a))
(#:end 3))
((< #:end a) nil)
(print :hello))
An alternative expansion, which doesn't use VAR in the control of the
iteration, is the following:
(defmacro dotimes ((var init &optional result) &body body)
(multiple-value-bind (body decl-specs)
(extract-declarations body)
(let ((iterator (gensym))
(end (gensym))
(loop (gensym)))
`(block nil
(let ((,iterator 0)
(,end (the integer ,init))) ; "should be integer"
(declare (type (integer 0) ,iterator))
(tagbody
,loop
(let ((,var ,iterator))
(declare ,@decl-specs) ; X3J13 DECLARATION-SCOPE
(if (<= ,end ,iterator)
(return ,result) ; VAR bound to # iterations
(tagbody ,@body)))
(incf ,iterator)
(go ,loop)))))))
For the dotimes in the example function, this expands into
(block nil
(let ((#:iterator 0)
(#:end (the integer 3)))
(declare (type (integer 0) #:iterator))
(tagbody
#:loop
(let ((a #:iterator))
(if (<= #:end #:iterator)
(return nil)
(tagbody
(print :hello))))
(incf #:iterator)
(go #:loop))))
and results in no references to the variable A.
The paragraph at the top of CLtL p.128 says that modification of the VAR within
the loop has unpredictable results. Using the first expansion it modifies the
variable for future iterations, while in the second such a modification has no
effect on future iterations.
There are other differences besides how IGNORE declarations would be
interpreted by these two expansions. If VAR is closed over, the first
expansion has a single binding whose value is modified during the iteration,
while the second has a distinct binding for each iteration. An example where
this makes a difference is
(let ((functions ()))
(dotimes (i 3)
(push #'(lambda () i) functions))
(mapcar #'funcall functions))
Using the first expansion, the result of this is (2 2 2), while using the
second expansion results in (2 1 0). I don't know of anything which would
imply that one or the other of these results is correct and the other
incorrect, though having two possible results for something like this is pretty
unpalatable.
Also note that there are examples in CLtL which don't use the iteration
variable and don't include IGNORE declarations (cf. p.88).
I agree with your comments regarding IGNORE being an assertion, and that it
also helps the reader. For this reason I believe warnings should be issued for
variables which are both used and declared IGNORE. But then there is the
question of the definition of "used" -- do only references count, or do
modifications count as uses too? We (IIM) discussed this at some length
internally, and while we currently count modifications as uses, we now think
this may be a mistake and are considering changing to only counting references.
The arguments for this have to do with code fragments like
(let ((var ...)
ignore)
(declare (ignore ignore))
...
(multiple-value-setq (ignore var) <form>)
...)
vs.
(let ((var ...))
...
(multiple-value-bind (ignore var-value)
<form>
(declare (ignore ignore))
(setq var var-value))
...)
kab
∂24-Jul-90 0943 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 09:43:05 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Tue 24 Jul 90 11:37:26-CDT
Return-Path: <barmar@Think.COM>
Received: from Sfs-Akv.Think.COM by mail.think.com; Tue, 24 Jul 90 12:37:21 -0400
Received: from OCCAM.THINK.COM by sfs-akv.think.com (4.0/Think-1.0C)
id AA03654; Tue, 24 Jul 90 12:37:14 EDT
Date: Tue, 24 Jul 90 12:36 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: DOTIMES
To: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Cc: Jon L White <jonl@lucid.com>, snicoud@atc.boeing.com, common-lisp@mcc.com
In-Reply-To: <26237.9007232226@subnode.aiai.ed.ac.uk>
Message-Id: <19900724163636.3.BARMAR@OCCAM.THINK.COM>
Date: Mon, 23 Jul 90 23:26:21 BST
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
> re: Given this function definition
> (defun test ()
> (dotimes (a 3)
> (print :hello)))
> Should/Must/Can a Common Lisp implementation warn of an unused
> variable (a)?
I'm inclined to say "no", because A is "used" to make the iteration
happen three times.
CLtL gives the implementor of DOTIMES license to use a different
variable to control the iteration. It says that altering A in the body
of the DOTIMES has unpredictable results.
But here is one place where we're paying the price for not offering
an "as if" expansion of the standard macros (when possible). Compare
this to the Scheme standard and Revised Reports. (I know there are
good reasons for not specifying with code, but if you don't you may
have to specify more things explicitly.
But it's hard to leave things intentionally vague when you specify with
code, unless you give all the different possibilities. For instance,
any of the following are valid implementations of DOTIMES:
(defmacro dotimes ((var count-form &optional result-form) &body body)
(let ((count-var (gensym)))
`(let ((,count-var ,count-form))
(do ((,var 0 (1+ ,var)))
((>= ,var ,count-var) ,result-form)
.,body))))
(defmacro dotimes ((var count-form &optional result-form) &body body)
(let ((count-var (gensym))
(iter-var (gensym)))
`(let ((,count-var ,count-form))
(do ((,iter-var 0 (1+ ,iter-var)))
((>= ,iter-var ,count-var)
(let ((,var ,iter-var))
,result-form))
(let ((,var ,iter-var))
.,body)))))
(defmacro dotimes-1 ((var count-form &optional result-form) &body body)
(let ((count-var (gensym))
(iter-var (gensym)))
`(let ((,count-var ,count-form))
(do ((,iter-var 0 (1+ ,iter-var))
(,var 0 (1+ ,var)))
((>= ,iter-var ,count-var)
,result-form)
.,body))))
and there are others (e.g. a CL implementation that does tail-recursion
optimization could be recursive, and it would still have the option of
recurring on the user-supplied or an internal variable). CL is careful
to restrict implementations only where it was felt that applications
need to be able to depend on the precise operation, and the binding
mechanism of DOTIMES was not felt to be one of them.
> Warning messages are a very stylistic matter, and aren't generally
> mandated or prohibited by CLtL. The existence of an IGNORE declaration
> *is* a standard (from CLtL); the issuance or quiescence of a warning based
> on it is merely marked "desirable" -- not a standard. At any rate, it's
> very unlikely that any non-compiling interpreter will warn you about this
> case; so it's really a compiler interface issue, about which there are few
> standards.
If this is supposed to be an argument that the standard needn't
address this issue, then I disagree. IGNORE declarations are very
like ASSERTions; and they provide information to human readers as
well as to implementations. They aren't just to avoid warnings
by to assert something about the code.
In my experience, most IGNORE declarations are to avoid warnings;
they're an improvement over the old practice of simply mentioning the
variable as an expression in the progn-body or as an argument to an
IGNORE function, but serve the same purpose. They're usually used when
the need to bind a variable is specified externally (e.g. by the
language specification of DOTIMES, or the specifier of a function
interface that has several implementations) rather than by the designer
of the function.
Once it was turned into a declaration someone got the bright idea that
it could be treated as an assertion, which the compiler could then
check.
Programmers ought to be able to write correct IGNORE declarations in
every case where a variable is not used and ought to be able to write
code in which every variable not subject to an IGNORE declaration *is*
used.
Macro writers have a hard time with this. Many macros bind variables
that the body *may* use, but isn't necessarily required to use.
If Common Lisp doesn't define "use" enough for this to be possible,
then the definition should be improved or else we should admit
defeat and say IGNORE declarations are a compiler interface issue
and so should not be part of standard Common Lisp.
If we can define "use" and IGNORE declarations without unnecessarily
restricting macro expansions, fine with me. In the case of DOTIMES,
either of the following would be reasonable forms for such a
specification.
* If the iteration variable is not used in the body or result form
the default shall be not to issue a warning, even if the
implementation normally warns about lexical variables that are bound
but not referenced. The consequences are unspecified if the iteration
variable is declared IGNORE. An implementation may define a way to
enable such a warning.
* If the iteration variable is not used in the body or result form
a warning may be issued, as with other lexical variables that
are bound but not referenced. An IGNORE declaration may be
included in the body to suppress this warning (in this case a warning
may be issued if the variable is used in the body or result form).
Another way to admit defeat would be to change the meaning of an
IGNORE declaration so that it says only that a variable *might not*
be used.
Or come up with a new declaration, such as IGNORABLE.
barmar
∂24-Jul-90 1003 Common-Lisp-mailer DOTIMES Variable
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 10:03:03 PDT
Received: from nrtc.northrop.com (GREMLIN.NRTC.NORTHROP.COM) by MCC.COM with TCP/SMTP; Tue 24 Jul 90 11:57:39-CDT
Received: from tribble by gremlin.nrtc.northrop.com id aa28364;
24 Jul 90 9:56 PDT
To: Common-Lisp@mcc.com
Subject: DOTIMES Variable
Date: Tue, 24 Jul 90 09:55:58 -0700
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
Consider the following forms (and others like them)
(DEFUN FOO (A IGNORE B) ...)
(FLET((FOO (A IGNORE B) ...) ...) ...)
(LET((A ...) (IGNORE ...) (B ...)) ...)
(MULTIPLE-VALUE-BIND (A IGNORE B) ...)
(DESTRUCTURING-BIND (A IGNORE B) (...) ...)
The gimmic is that common lisp allows IGNORE to be used in lieu of
a variable binding name ALMOST everywhere in the language. Obviously,
my suggestion is that
(DO (IGNORE 3) ...)
solve the current problem. In fact, I believe that this should become
offical common (lisp) law---IGNORE can always be used where the language
demands a variable name to bind.
Jeff
∂24-Jul-90 1105 Common-Lisp-mailer DOTIMES Variable
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 11:05:44 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Tue 24 Jul 90 13:02:12-CDT
Return-Path: <barmar@Think.COM>
Received: from Sfs-Akv.Think.COM by mail.think.com; Tue, 24 Jul 90 14:02:07 -0400
Received: from OCCAM.THINK.COM by sfs-akv.think.com (4.0/Think-1.0C)
id AA03809; Tue, 24 Jul 90 14:02:05 EDT
Date: Tue, 24 Jul 90 14:02 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: DOTIMES Variable
To: Jeff Barnett <jbarnett@nrtc.northrop.com>
Cc: Common-Lisp@mcc.com
In-Reply-To: <9007241704.AA11407@gateway.think.com>
Message-Id: <19900724180200.9.BARMAR@OCCAM.THINK.COM>
Date: Tue, 24 Jul 90 09:55:58 -0700
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
Consider the following forms (and others like them)
(DEFUN FOO (A IGNORE B) ...)
(FLET((FOO (A IGNORE B) ...) ...) ...)
(LET((A ...) (IGNORE ...) (B ...)) ...)
(MULTIPLE-VALUE-BIND (A IGNORE B) ...)
(DESTRUCTURING-BIND (A IGNORE B) (...) ...)
The gimmic is that common lisp allows IGNORE to be used in lieu of
a variable binding name ALMOST everywhere in the language.
What do you mean "in lieu of a variable". Those examples are binding a
variable named IGNORE.
Obviously,
my suggestion is that
(DO (IGNORE 3) ...)
solve the current problem. In fact, I believe that this should become
offical common (lisp) law---IGNORE can always be used where the language
demands a variable name to bind.
Jeff
Are you proposing that Common Lisp adopt the Lisp Machine kludge of
automatically ignoring a variable named IGNORE? That's one of the
things (DECLARE (IGNORE ...)) was invented to replace.
barmar
∂24-Jul-90 1136 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 11:36:29 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 24 Jul 90 13:30:44-CDT
Received: from dime.cs.umass.edu by SAIL.Stanford.EDU with TCP; 24 Jul 90 11:29:04 PDT
Received: from vax3.cs.umass.edu by dime.cs.umass.edu (5.61/Ultrix2.0-B)
id AA28651; Tue, 24 Jul 90 14:30:01 -0400
Date: Tue, 24 Jul 90 14:20 EST
From: ELIOT@cs.umass.EDU
Subject: DOTIMES
To: common-lisp@sail.stanford.EDU
Message-Id: <5D875E1F4A5F20032E@cs.umass.EDU>
X-Envelope-To: common-lisp@sail.stanford.EDU
X-Vms-To: IN%"common-lisp@sail.stanford.EDU"
X-Vms-Cc: ELIOT
Given how well (declare (ignore ...)) has been specified and implemented
I find it is simply better to never use it. The old trick of simply
using the variable gratuitously works just fine and does exactly what
I want.
Declare ignore is totally useless unless (1) every implementation is *required*
to suppress the relevant unused variable warnings, and (2) no error message
about ignored variables being used can be issued unless the variable is
used by *user visible* code. The construct is not at all portable if
its meaning depends upon how a macro like DOTIMES gets expanded.
∂24-Jul-90 1226 Common-Lisp-mailer IGNORE declarations
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 12:26:52 PDT
Received: from ALEXANDER.BBN.COM by MCC.COM with TCP/SMTP; Tue 24 Jul 90 14:22:42-CDT
To: common-lisp@mcc.com
cc: fwhite@BBN.COM
Subject: IGNORE declarations
Date: Tue, 24 Jul 90 15:17:50 -0400
From: Fredric M White <fwhite@BBN.COM>
I would think that
(proclaim '(ignore ignore))
would enable the "lisp machine kludge" (except for allowing ignore to
appear more than once in a lambda list). But I haven't seen it work
in any common lisp I've tried.
--Fred White
∂24-Jul-90 1315 Common-Lisp-mailer IGNORE declarations
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 13:15:31 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Tue 24 Jul 90 15:10:06-CDT
Return-Path: <barmar@Think.COM>
Received: from Sfs-Akv.Think.COM by mail.think.com; Tue, 24 Jul 90 16:09:56 -0400
Received: from OCCAM.THINK.COM by sfs-akv.think.com (4.0/Think-1.0C)
id AA03980; Tue, 24 Jul 90 16:09:53 EDT
Date: Tue, 24 Jul 90 16:09 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: IGNORE declarations
To: Fredric M White <fwhite@BBN.COM>
Cc: common-lisp@mcc.com
In-Reply-To: <9007241928.AA12351@gateway.think.com>
Message-Id: <19900724200951.3.BARMAR@OCCAM.THINK.COM>
Date: Tue, 24 Jul 90 15:17:50 -0400
From: Fredric M White <fwhite@BBN.COM>
I would think that
(proclaim '(ignore ignore))
would enable the "lisp machine kludge" (except for allowing ignore to
appear more than once in a lambda list). But I haven't seen it work
in any common lisp I've tried.
Not really. The Lisp Machine ignores any argument variable that is
STRING-EQUAL to "IGNORE" or "IGNORED".
barmar
∂24-Jul-90 1340 Common-Lisp-mailer IGNORE
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 13:40:13 PDT
Received: from venera.isi.edu by MCC.COM with TCP/SMTP; Tue 24 Jul 90 15:27:07-CDT
Received: from hpai23.isi.edu by venera.isi.edu (5.61/5.61+local)
id <AA12828>; Tue, 24 Jul 90 13:24:59 -0700
Posted-Date: Tue, 24 Jul 90 16:24:39 EDT
Message-Id: <9007242024.AA17629@hpai23>
Received: by hpai23 (14.5/4.0.3-3)
id AA17629; Tue, 24 Jul 90 16:24:43 edt
To: common-lisp@mcc.com
From: goldman@venera.isi.edu
Subject: IGNORE
Cc: gls@think.com, jeff@aiai.edinburgh.ac.uk, jonl@lucid.com,
snicoud@atc.boeing.com
Date: Tue, 24 Jul 90 16:24:39 EDT
Sender: goldman@venera.isi.edu
> (dotimes (a 3)
> (print :hello)))
> Should/Must/Can a Common Lisp implementation warn of an unused
> variable (a)?
> I'm inclined to say "no", because A is "used" to make the iteration
> happen three times.
Are you also inclined to say that V is not ignored in
(mapcar #'(lambda (V) t) l)
because it is "used" to consume an argument being passed? I think
a definition of "use" based on the ability to use the
word "use" in describing the variable is pretty USEless.
This discussion is not of interest SOLELY or even PRIMARILY
because CL lacks a REPEAT construct, useful though that may be.
The same issue can arise with other system macros --
DOLIST and WITH-OPEN-FILE come to mind. There is also an implication
for the proper way for programmers to code macros that allow the caller
to supply DECLARATIONS in the call.
I think that such macros, whether vendor-supplied or written by
programmers, should NOT introduce code in the expansion that could
invalidate otherwise correct declarations UNLESS they also modify or
suitably scope the declarations in the expansion -- e.g., it is fine for
(dotimes (a n)
(declare (special zzz)(ignore a) (inline foo))
(foo zzz))
to expand into
(DO ((A 0 (1+ A)))
((>= A N) NIL)
(DECLARE (SPECIAL ZZZ) (INLINE FOO))
(FOO ZZZ))
but not
(DO ((A 0 (1+ A)))
((>= A N) NIL)
(DECLARE (SPECIAL ZZZ) (IGNORE A) (INLINE FOO))
(FOO ZZZ))
Of course, if the macro is SPECIFIED to produce code in its expansion
that references a variable, or binds it to NIL, or whatever, then
its expander should not need to be concerned with
declarations in the call that would be violated by the additional code.
Is there really a good reason why some macros need to be specified,
in essence, as MAYBE producing code that impacts the correctness of
declarations?
Notice that it is not only IGNORE declarations that could be violated
by code introduced in macro expansions. Consider:
(dotimes (j n (foo j))
(declare (type (mod 3) j))
(whatever j))
Is that legal, assuming N is always of type (mod 3)? Reading the
definition of DOTIMES in CLtL, I might suspect that J only takes on
the values between 0 and N, inclusive, making the declaration valid.
But could a legal CL implementation expand this into
(let ((j -1))
(declare (type (mod 3) j)) ;; now illegal
(loop (when (>= (incf j) n) (return (foo j)))
(whatever j)))
It seems to me that when a macro's syntax has a place for
{declaration}*, there should be
o no question what kinds of declaration are meaningful, and
o no question about their scope.
Furthermore, if at all possible that scope
should be specified in terms of the other syntactic units of the macro.
-- neil
∂24-Jul-90 1359 Common-Lisp-mailer IGNORE declarations
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 13:59:03 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Tue 24 Jul 90 15:45:21-CDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 824611; 24 Jul 90 16:43:57 EDT
Date: Tue, 24 Jul 90 16:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE declarations
To: fwhite@BBN.COM
cc: common-lisp@mcc.com
In-Reply-To: The message of 24 Jul 90 15:17 EDT from Fredric M White <fwhite@BBN.COM>
Message-ID: <19900724204352.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Tue, 24 Jul 90 15:17:50 -0400
From: Fredric M White <fwhite@BBN.COM>
I would think that
(proclaim '(ignore ignore))
would enable the "lisp machine kludge" (except for allowing ignore to
appear more than once in a lambda list). But I haven't seen it work
in any common lisp I've tried.
Most compiler writers contend that IGNORE is not a pervasive proclamation
and hence can't apply to any binding of IGNORE within the scope of this
proclamation, hence making the above form fairly useless.
For what it's worth, when I converted Macsyma to Common Lisp a few years
ago, it made heavy use of the LispM IGNORE variable kludge and I used the
interim workaround
(proclaim '(special ignore))
which works pretty well as a stopgap (albeit causing a slight bit in
performance due to a bunch of unneeded special bindings :-).
Btw, I plan to bring this up as an X3J13 cleanup issue at the next meeting,
so with any luck the ANSI draft might be more clear than CLtL was on this
issue. Cross your fingers.
∂24-Jul-90 1512 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 15:12:32 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 24 Jul 90 17:08:56-CDT
Received: from venera.isi.edu by SAIL.Stanford.EDU with TCP; 24 Jul 90 15:06:58 PDT
Received: from hpai23.isi.edu by venera.isi.edu (5.61/5.61+local)
id <AA17526>; Tue, 24 Jul 90 15:08:22 -0700
Posted-Date: Tue, 24 Jul 90 18:08:03 EDT
Message-Id: <9007242208.AA18073@hpai23>
Received: by hpai23 (14.5/4.0.3-3)
id AA18073; Tue, 24 Jul 90 18:08:07 edt
Subject: DOTIMES
To: common-lisp@sail.stanford.edu
Date: Tue, 24 Jul 90 18:08:03 EDT
From: Don Cohen <donc@venera.isi.edu>
re:
Given how well (declare (ignore ...)) has been specified and implemented
I find it is simply better to never use it. The old trick of simply
using the variable gratuitously works just fine and does exactly what
I want.
I disagree. It looks to me like an implementor would be perfectly justified
in claiming that the "gratuitous" use was not a use at all (if the compiler
were smart enough to realize that it could be optimized out).
I've had trouble finding sets of declarations that portably avoided warnings.
I'd like to see some way of declaring that I'm not interested in certain
kinds of warnings (perhaps over certain scopes). This is especially a problem
when you write hairy macros - it's hard enough to get them to do what you want
without having to go back and figure out what declarations to insert in order
to avoid all sorts of warnings.
∂24-Jul-90 1525 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 15:25:31 PDT
Received: from NSFnet-Relay.AC.UK by MCC.COM with TCP/SMTP; Tue 24 Jul 90 17:17:31-CDT
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa19186; 24 Jul 90 21:18 BST
Date: Tue, 24 Jul 90 21:26:10 BST
Message-Id: <208.9007242026@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: DOTIMES
To: "Kim A. Barrett" <kab@charon.mit.edu>
In-Reply-To: Kim A. Barrett's message of Tue, 24 Jul 90 11:35:06 EDT
Cc: jonl@lucid.com, snicoud@atc.boeing.com, common-lisp@mcc.com
> >> (defun test ()
> >> (dotimes (a 3)
> >> (print :hello)))
>
> >> Should/Must/Can a Common Lisp implementation warn of an unused
> >> variable (a)?
>
> > I'm inclined to say "no", because A is "used" to make the iteration
> > happen three times.
>
> Actually, things aren't so simple. When you say that the variable is being
> used to control the iteration, you are assuming a particular expansion
Well, I'm assuming a particular semantics, which I think is better
in certain ways than having no particular semantics. The semantics
could be inplemented by a variety of expansions.
∂24-Jul-90 1605 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 24 Jul 90 16:05:48 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Tue 24 Jul 90 18:00:13-CDT
Return-Path: <barmar@Think.COM>
Received: from Sfs-Akv.Think.COM by mail.think.com; Tue, 24 Jul 90 19:00:09 -0400
Received: from OCCAM.THINK.COM by sfs-akv.think.com (4.0/Think-1.0C)
id AA04192; Tue, 24 Jul 90 19:00:07 EDT
Date: Tue, 24 Jul 90 19:00 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: DOTIMES
To: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Cc: Kim A. Barrett <kab@charon.mit.edu>, jonl@lucid.com,
snicoud@atc.boeing.com, common-lisp@mcc.com
In-Reply-To: <208.9007242026@subnode.aiai.ed.ac.uk>
Message-Id: <19900724230004.1.BARMAR@OCCAM.THINK.COM>
Date: Tue, 24 Jul 90 21:26:10 BST
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
> >> (defun test ()
> >> (dotimes (a 3)
> >> (print :hello)))
>
> >> Should/Must/Can a Common Lisp implementation warn of an unused
> >> variable (a)?
>
> > I'm inclined to say "no", because A is "used" to make the iteration
> > happen three times.
>
> Actually, things aren't so simple. When you say that the variable is being
> used to control the iteration, you are assuming a particular expansion
Well, I'm assuming a particular semantics, which I think is better
in certain ways than having no particular semantics. The semantics
could be inplemented by a variety of expansions.
The only semantics you are safe to assume are the ones specified in
CLtL. It says "it then performs <progbody> once for each integer from
zero (inclusive) to <count> (exclusive), in order, with the variable
<var> bound to the integer...." How the variable gets that binding is
not something you may portably assume.
barmar
∂25-Jul-90 1335 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 25 Jul 90 13:35:52 PDT
Received: from NSFnet-Relay.AC.UK by MCC.COM with TCP/SMTP; Wed 25 Jul 90 15:24:27-CDT
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa14679; 25 Jul 90 21:10 BST
Date: Wed, 25 Jul 90 21:18:20 BST
Message-Id: <4228.9007252018@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: DOTIMES
To: Barry Margolin <barmar@think.com>
In-Reply-To: Barry Margolin's message of Tue, 24 Jul 90 12:36 EDT
Cc: Jon L White <jonl@lucid.com>, snicoud@atc.boeing.com, common-lisp@mcc.com
Sigh. I meant to make a more significant point in my response to
Kim Barrett yesterday (rather than just say I was assuming a semantics
rather than an expansion) but I made a mistake with the mail software
and sent an unfinished message. Let me try again.
The sample code is:
(defun test ()
(dotimes (a 3)
(print :hello)))
And the question is:
Should/Must/Can a Common Lisp implementation warn of an unused
variable (a)?
As both Ken Barrett and Barry Margolin have explained in detail, CltL
doesn't say enough about DOTIMES to give this question a definite
answer. Indeed CLtL doesn't even say whether the variable gets its
values by binding (ie so there's a new variable each time) or
assignment. However, it does say the variable is "bound" to the
integers (p 127), which is perhaps slightly misleading.
In this situation, the user can't win. Some implementations may give
a warning if there is an IGNORE declaration (because the variable is
used given the expansion of the DOTIMES); other implementations may
give a warning if there isn't an IGNORE declaration.
This sort of thing is a pain for programmers and also makes Common
Lisp look bad. ("Common Lisp is too complex", "There are unexpected
interactions between the parts", etc.)
I think we have to ask whether the implementation flexibility allowed
by the definition of DOTIMES is worth it. Sometimes it is better to
have a certain flexibility, but not always.
Both the R3RS and CLtL explain DO in terms of an equivalent expression
using more primitive constructs; that is, they give an expansion.
However, this doesn't mean DO has to expand that way. It could
expand into something else, provided it was equivalent. (Hence
my remark on assuming semantics rather than expansion.)
Why is this ok for DO but not for DOTIMES? What is the benefit
that makes the imprecision in the definition of DOTIMES worthwhile?
Note too that we could go part way and specify more about DOTIMES
than we do now while still saying less than we do about DO.
Why shouldn't we specify enough so as to eliminate this problem
with IGNORE?
> But it's hard to leave things intentionally vague when you specify with
> code, unless you give all the different possibilities.
That depends on just what flexibility you want to allow. Specifying
some code and saying the behavior must be as if that expansion were
used still allows a degree of flexibility. For example, I would
expect the following expansion of the sample code would be allowed
by most reasonable definitions:
(dotimes (a 3) (progn (print :hello)
(print :hello))) ==> (print :hello)
(print :hello))
> and there are others (e.g. a CL implementation that does tail-recursion
> optimization could be recursive, and it would still have the option of
> recurring on the user-supplied or an internal variable).
CLtL gives equivalent code for DO. If it rules out the kind of
tail-recursion you want, why is it important to do something different
for DOTIMES? If it allows the kind of tail-recursion you want, why is
that degree of precision a problem?
Moreover, the definition of DOTIMES wouldn't have to say the
variable gets its new value as if by SETQ. It could say there
is a new binding each time, which would allow a straightforward
tail-recursive implementation.
I realize tail-recursion is just one example. However, it looks
like an alternative it might be worthwhile to allow. That may not
be true of all the others.
> CL is careful to restrict implementations only where it was felt that
> applications need to be able to depend on the precise operation, and
> the binding mechanism of DOTIMES was not felt to be one of them.
Yes, but now we see that there are certain consequences of that
decision.
> In my experience, most IGNORE declarations are to avoid warnings;
> they're an improvement over the old practice of simply mentioning the
> variable ...
> Once it was turned into a declaration someone got the bright idea that
> it could be treated as an assertion, which the compiler could then
> check.
I agree that it started as a way to avoid warnings. But it doesn't
work reliably even for that, given the variations allowed for DOTIMES.
> Programmers ought to be able to write correct IGNORE declarations in
> every case where a variable is not used and ought to be able to write
> code in which every variable not subject to an IGNORE declaration *is*
> used.
>
> Macro writers have a hard time with this. Many macros bind variables
> that the body *may* use, but isn't necessarily required to use.
I would at least like such things to be possible as far as the
standard macros are concerned.
As for other macros, I don't think it's completely unreasonable
to ask that macros be defined in such a way that if a user does
not use one of these variables that may be used, an IGNORE
declaration won't be incorrect.
Of course, it will still be possible to write macros that do
not have this property. It will just make things a little
harder for users who want to use IGNORE.
In any case, bear in mind that macros often want to define
functions or macros that the body will use, and then IGNORE
doesn't apply. I suspect this case is the more common one.
> If we can define "use" and IGNORE declarations without unnecessarily
> restricting macro expansions, fine with me. In the case of DOTIMES,
> either of the following would be reasonable forms for such a
> specification.
I would prefer a solution where the definition of DOTIMES didn't
have to mention the IGNORE declaration explicitly.
> Another way to admit defeat would be to change the meaning of an
> IGNORE declaration so that it says only that a variable *might not*
> be used.
>
> Or come up with a new declaration, such as IGNORABLE.
True.
-- Jeff
∂25-Jul-90 1506 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 25 Jul 90 15:06:22 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Wed 25 Jul 90 17:00:16-CDT
Return-Path: <barmar@Think.COM>
Received: from Sfs-Akv.Think.COM by mail.think.com; Wed, 25 Jul 90 18:00:10 -0400
Received: from OCCAM.THINK.COM by sfs-akv.think.com (4.0/Think-1.0C)
id AA06237; Wed, 25 Jul 90 18:00:05 EDT
Date: Wed, 25 Jul 90 17:59 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: DOTIMES
To: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Cc: Jon L White <jonl@lucid.com>, snicoud@atc.boeing.com, common-lisp@mcc.com
In-Reply-To: <4228.9007252018@subnode.aiai.ed.ac.uk>
Message-Id: <19900725215952.1.BARMAR@OCCAM.THINK.COM>
Date: Wed, 25 Jul 90 21:18:20 BST
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Both the R3RS and CLtL explain DO in terms of an equivalent expression
using more primitive constructs; that is, they give an expansion.
However, this doesn't mean DO has to expand that way. It could
expand into something else, provided it was equivalent. (Hence
my remark on assuming semantics rather than expansion.)
X3J13 has wrestled with this issue in the past, including during
face-to-face committee meetings. Some people are strongly against
defining one construct in terms of another, while others would like to
do more of it.
The hard part is defining "equivalent". If the language defines two
constructs to be equivalent a user-written code walker might expect to
make such a substitution without it affecting the behavior. Must the
two constructs have equivalent performance (the only place where CLtL
addresses this is in the definition of 1+ and 1-, which says that they
should have the same performance as calling + and - with a second
argument of 1). Must they appear equivalent to the user if he ends up
in the debugger in the middle of the construct?
Also, implementations may extend Common Lisp constructs so that they
have implementation-dependent side effects on implementation-specific
data. For instance, DEFUN may save away function cross-reference and
source file location information, making it inequivalent to SETF of
SYMBOL-FUNCTION. For the most part such differences won't be noticed by
other Common Lisp code; however, if the extensions add entries to symbol
property lists then a caller of SYMBOL-PLIST would be able to detect the
difference.
So, in order to use the word "equivalent" formally, we would have to
come up with a precise list of the aspects of the behavior that must be
common within such an equivalence class.
Why is this ok for DO but not for DOTIMES? What is the benefit
that makes the imprecision in the definition of DOTIMES worthwhile?
Iterating over consecutive integers has a long history in computer
science, and CPUs tend to have special instructions tailored for use by
such loops. The implementor of DOTIMES might want to take advantage of
such instructions, even though they would not be generated by any other
equivalent Common Lisp code. We shouldn't define DOTIMES so as to
preclude an implementor from using their hardware to the fullest extent.
For instance, in some cases, when the Symbolics DOTIMES notices that the
iteration variable isn't used, it counts down instead of up, in order to
take advantage of a "decrement and branch if non-zero" instruction.
DO, on the other hand, is general enough that it's unlikely to map
directly onto specialized machine instructions. Specifying it more
precisely provides some benefit to the user without hindering the
implementor much.
Thus, the user can choose to use DOTIMES when he needs a really fast
counter and doesn't need to assume much about the semantics, or to use
DO when the precise semantics are more important than the performance.
Most counting loops don't need to set the iteration variable in the body
or return a closure, so it's pretty rare that the semantic differences
are an issue.
> But it's hard to leave things intentionally vague when you specify with
> code, unless you give all the different possibilities.
That depends on just what flexibility you want to allow. Specifying
some code and saying the behavior must be as if that expansion were
used still allows a degree of flexibility. For example, I would
expect the following expansion of the sample code would be allowed
by most reasonable definitions:
(dotimes (a 3) (progn (print :hello)
(print :hello))) ==> (print :hello)
(print :hello))
But the standard can't specify equivalences in this way, it has to
define things generally. It's not correct to extrapolate from that
example:
(dotimes (a 3) (progn <form>
<form>) ==> <form>
<form>)
> CL is careful to restrict implementations only where it was felt that
> applications need to be able to depend on the precise operation, and
> the binding mechanism of DOTIMES was not felt to be one of them.
Yes, but now we see that there are certain consequences of that
decision.
This whole discussion started because there's an implementation of
DOTIMES that issues a warning when the iteration variable isn't
referenced in the user-supplied body. Should we really be changing the
language in a way that may affect performance because of a style
warning? As far as I know, no one has complained about portability
problems due to different implementations' binding and assignment
methods in the DOTIMES expansion; all they want is a portable way to
turn off the warning.
By the way, the solution we use in our code is:
(dotimes (i <count>)
#+smart-iteration (declare (ignore i))
<body>)
An early module in our software pushes :SMART-ITERATION onto *FEATURES*
in implementations that are known to produce the warning, so the
implementation-dependent code is not littered throughout our software.
> In my experience, most IGNORE declarations are to avoid warnings;
> they're an improvement over the old practice of simply mentioning the
> variable ...
> Once it was turned into a declaration someone got the bright idea that
> it could be treated as an assertion, which the compiler could then
> check.
I agree that it started as a way to avoid warnings. But it doesn't
work reliably even for that, given the variations allowed for DOTIMES.
So Common Lisp isn't perfect; what else is new?
> Programmers ought to be able to write correct IGNORE declarations in
> every case where a variable is not used and ought to be able to write
> code in which every variable not subject to an IGNORE declaration *is*
> used.
>
> Macro writers have a hard time with this. Many macros bind variables
> that the body *may* use, but isn't necessarily required to use.
I would at least like such things to be possible as far as the
standard macros are concerned.
As for other macros, I don't think it's completely unreasonable
to ask that macros be defined in such a way that if a user does
not use one of these variables that may be used, an IGNORE
declaration won't be incorrect.
Of course, it will still be possible to write macros that do
not have this property. It will just make things a little
harder for users who want to use IGNORE.
In any case, bear in mind that macros often want to define
functions or macros that the body will use, and then IGNORE
doesn't apply. I suspect this case is the more common one.
I'm not sure what it is you're saying. The kind of macro I'm thinking
of is:
(defmacro with-symbol-variables (symbol-form &body body)
(let ((symbol-var (gensym)))
`(let ((,symbol-var ,symbol-form))
(let ((plist (symbol-plist ,symbol-var))
(value (and (boundp ,symbol-var) (symbol-value ,symbol-var)))
(function (and (fboundp ,symbol-var) (symbol-function ,symbol-var)))
(package (symbol-package ,symbol-var)))
.,body))))
(defun print-package-and-plist (symbol)
(with-symbol-variables symbol
(format t "~S's package is ~A, its plist is ~S." symbol package plist)))
Most compilers would warn that PRINT-PACKAGE-AND-PLIST binds the
variables VALUE and FUNCTION without using them. In order to suppress
this warning you have to write:
(defun print-package-and-plist (symbol)
(with-symbol-variables symbol
(declare (ignore value function))
(format t "~S's package is ~A, its plist is ~S." symbol package plist)))
There's nothing portable we can put in the definition of
WITH-SYMBOL-VARIABLES that would indicate that users of the macro are
not expected to reference all the variables that are bound by it
(however, one would probably still want a warning if *none* of the
variables are referenced).
> If we can define "use" and IGNORE declarations without unnecessarily
> restricting macro expansions, fine with me. In the case of DOTIMES,
> either of the following would be reasonable forms for such a
> specification.
I would prefer a solution where the definition of DOTIMES didn't
have to mention the IGNORE declaration explicitly.
Why? The only complaint I've heard about DOTIMES is that it's
unspecified whether an IGNORE declaration for the iteration variable is
allowed. DOTIMES is the only Common Lisp construct I can think of that
forces the user to bind a variable that he might not need (I suppose
DOLIST and DO-SYMBOLS also do, but it seems pretty unlikely that someone
would iterate over a list or package without needing to access the list
elements or symbols).
barmar
∂26-Jul-90 0934 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 26 Jul 90 09:34:04 PDT
Received: from NSFnet-Relay.AC.UK by MCC.COM with TCP/SMTP; Thu 26 Jul 90 11:22:35-CDT
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa09668; 26 Jul 90 17:09 BST
Date: Thu, 26 Jul 90 17:18:16 BST
Message-Id: <7428.9007261618@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: DOTIMES
To: Barry Margolin <barmar@think.com>
In-Reply-To: Barry Margolin's message of Wed, 25 Jul 90 17:59 EDT
Cc: Jon L White <jonl@lucid.com>, snicoud@atc.boeing.com, common-lisp@mcc.com
> X3J13 has wrestled with this issue in the past, including during
> face-to-face committee meetings. Some people are strongly against
> defining one construct in terms of another, while others would like to
> do more of it.
>
> The hard part is defining "equivalent". If the language defines two
> constructs to be equivalent a user-written code walker might expect to
> make such a substitution without it affecting the behavior. Must the
> two constructs have equivalent performance (the only place where CLtL
> addresses this is in the definition of 1+ and 1-, which says that they
> should have the same performance as calling + and - with a second
> argument of 1). Must they appear equivalent to the user if he ends up
> in the debugger in the middle of the construct?
I am really surprised by this line of argument. I am well aware that
it is difficult to define "equivalent" precisely. Nonetheless, both
CLtL and the Scheme Reports use this approach in a number of cases,
and I don't notice anyone flaming them for it.
In any case, I'm talking about using this technique in the same way
it's already used, not to specify even more.
CLtL doesn't say anything at all about what appears to the debugger,
nor does it specify exact expansions. Indeed, the whole point of
talking about equivalence is to avoid that.
Code walkers already have to make decisions about the extent to which
they preserve the original code.
Moreover, we already have to define what the compiler can do. Most,
if not all, of the problems of equivalence come up there too. If
equivalence is really such a problem, why don't we hold up all Lisp
standards until we can define "equivalent" well enough to say what the
the compiler does?
> Why is this ok for DO but not for DOTIMES? What is the benefit
> that makes the imprecision in the definition of DOTIMES worthwhile?
>
> Iterating over consecutive integers has a long history in computer
> science, and CPUs tend to have special instructions tailored for use by
> such loops. The implementor of DOTIMES might want to take advantage of
> such instructions, even though they would not be generated by any other
> equivalent Common Lisp code. We shouldn't define DOTIMES so as to
> preclude an implementor from using their hardware to the fullest extent.
> For instance, in some cases, when the Symbolics DOTIMES notices that the
> iteration variable isn't used, it counts down instead of up, in order to
> take advantage of a "decrement and branch if non-zero" instruction.
The implementator should still be able to take advanatge of most,
if not all, hardware tricks. In particular, Symbolics could still
count down when the variable isn't used in the user's code.
If it turns out that we can't come up with a definition of DOTIMES
that allows enough optimizations, however, then that may be enough
reason to leave it vague.
> DO, on the other hand, is general enough that it's unlikely to map
> directly onto specialized machine instructions. Specifying it more
> precisely provides some benefit to the user without hindering the
> implementor much.
Specific cases of DO, however, are another matter. If compilers
handle the cases that result from DOTIMES well, they've solved two
problems at once. If you want to argue that DO is too hard to
optimize, I would disagree. C's "for" is not all that different from
DO, and C compilers seem to do pretty well.
> > But it's hard to leave things intentionally vague when you specify with
> > code, unless you give all the different possibilities.
>
> That depends on just what flexibility you want to allow. Specifying
> some code and saying the behavior must be as if that expansion were
> used still allows a degree of flexibility. For example, I would
> expect the following expansion of the sample code would be allowed
> by most reasonable definitions:
>
> (dotimes (a 3) (progn (print :hello)
> (print :hello))) ==> (print :hello)
> (print :hello))
>
> But the standard can't specify equivalences in this way, it has to
> define things generally.
No kidding. That's why I said that sample expansion would be
*allowed by the definition*. I wasn't suggesting that it *was*
the definition or even part of it.
> It's not correct to extrapolate from that example:
>
> (dotimes (a 3) (progn <form>
> <form>) ==> <form>
> <form>)
But I never said or implied that my example would be extrapolated in
that way. Just as Symbolics can notice when the loop counter isn't
used, so can I.
You seem so keen to rubbish my argument that you're not bothering
to try to see if I might have meant something more reasonable than
you thought at first glance.
> This whole discussion started because there's an implementation of
> DOTIMES that issues a warning when the iteration variable isn't
> referenced in the user-supplied body. Should we really be changing the
> language in a way that may affect performance because of a style
> warning?
We should make the specification more complete and precise unless
there is a good reason not to. I addressed performance above. Do you
really think Common Lisp would be worse off in performance relative to
C, for example, if DOTIMES were eliminated and programmers used DO?
Do you think the difference would be large enough (compared to CL
with DOTIMES) for anyone to care? I don't.
> As far as I know, no one has complained about portability
> problems due to different implementations' binding and assignment
> methods in the DOTIMES expansion; all they want is a portable way to
> turn off the warning.
You can't expect all problems to appear by a given date. X3J13
noticed probelms in roughly that area, however. See page 178
of CLtL II.
> I agree that it started as a way to avoid warnings. But it doesn't
> work reliably even for that, given the variations allowed for DOTIMES.
>
> So Common Lisp isn't perfect; what else is new?
I see. So we shouldn't try to improve it?
> I would prefer a solution where the definition of DOTIMES didn't
> have to mention the IGNORE declaration explicitly.
>
> Why?
Because it's a patch. We should try for orthogonality rather than
ad hoc solutions to special cases.
> The only complaint I've heard about DOTIMES is that it's unspecified
> whether an IGNORE declaration for the iteration variable is allowed.
I can turn some of the comments about assignment vs binding into
complaints if you'd like. Ditto the POP or not on page 178.
I'll address your macro example in a separate message. This one's
too long as it is.
-- Jeff
∂26-Jul-90 0953 Common-Lisp-mailer DOTIMES, part 2
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 26 Jul 90 09:53:03 PDT
Received: from NSFnet-Relay.AC.UK by MCC.COM with TCP/SMTP; Thu 26 Jul 90 11:41:26-CDT
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa09993; 26 Jul 90 17:24 BST
Date: Thu, 26 Jul 90 17:32:58 BST
Message-Id: <7581.9007261632@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: DOTIMES, part 2
To: Barry Margolin <barmar@think.com>
In-Reply-To: Barry Margolin's message of Wed, 25 Jul 90 17:59 EDT
Cc: Jon L White <jonl@lucid.com>, snicoud@atc.boeing.com, common-lisp@mcc.com
Programmers ought to be able to write correct IGNORE
declarations in every case where a variable is not used and
ought to be able to write code in which every variable not
subject to an IGNORE declaration *is* used.
Macro writers have a hard time with this. Many macros bind
variables that the body *may* use, but isn't necessarily required
to use.
I would at least like such things to be possible as far as the
standard macros are concerned.
As for other macros, I don't think it's completely unreasonable to
ask that macros be defined in such a way that if a user does not use
one of these variables that may be used, an IGNORE declaration won't
be incorrect.
> Most compilers would warn that PRINT-PACKAGE-AND-PLIST binds the
> variables VALUE and FUNCTION without using them. In order to suppress
> this warning you have to write:
>
> (defun print-package-and-plist (symbol)
> (with-symbol-variables symbol
> (declare (ignore value function))
> (format t "~S's package is ~A, its plist is ~S." symbol package plist)))
And is that IGNORE declaration incorrect? Or might a (correct)
compiler issue a warning saying the variable is used? My suggestion
was that macros should be written (not must be) so that such a
declaration would be correct.
-- Jeff
∂26-Jul-90 1253 Common-Lisp-mailer Please Remove Me
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 26 Jul 90 12:53:21 PDT
Received: from timbuk.CRAY.COM by MCC.COM with TCP/SMTP; Thu 26 Jul 90 14:16:40-CDT
Received: from hall.cray.com by timbuk.CRAY.COM (4.1/SMI4.0 CRAY1.1)
id AA16899; Thu, 26 Jul 90 14:16:24 CDT
Received: from balboa.cray.com by hall.cray.com
id AA06292; 4.1/CRI-3.14; Thu, 26 Jul 90 14:16:11 CDT
Received: by balboa.cray.com
id AA00577; 4.1/CRI-3.12; Thu, 26 Jul 90 14:10:03 CDT
Date: Thu, 26 Jul 90 14:10:03 CDT
From: denny@hall.cray.com (Denny Olson)
Message-Id: <9007261910.AA00577@balboa.cray.com>
To: common-lisp@mcc.com
Subject: Please Remove Me
Please remove me from this email list.
Thanks.
Denton (Denny) Olson
Cray Research, Inc.
∂26-Jul-90 1320 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 26 Jul 90 13:20:44 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Thu 26 Jul 90 15:04:16-CDT
Return-Path: <barmar@Think.COM>
Received: from Sfs-Akv.Think.COM by mail.think.com; Thu, 26 Jul 90 16:04:09 -0400
Received: from OCCAM.THINK.COM by sfs-akv.think.com (4.0/Think-1.0C)
id AA07471; Thu, 26 Jul 90 16:04:04 EDT
Date: Thu, 26 Jul 90 16:03 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: DOTIMES
To: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Cc: Jon L White <jonl@lucid.com>, snicoud@atc.boeing.com, common-lisp@mcc.com
In-Reply-To: <7428.9007261618@subnode.aiai.ed.ac.uk>
Message-Id: <19900726200357.9.BARMAR@OCCAM.THINK.COM>
Date: Thu, 26 Jul 90 17:18:16 BST
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
> X3J13 has wrestled with this issue in the past, including during
> face-to-face committee meetings. Some people are strongly against
> defining one construct in terms of another, while others would like to
> do more of it.
>
> The hard part is defining "equivalent". If the language defines two
> constructs to be equivalent a user-written code walker might expect to
> make such a substitution without it affecting the behavior. Must the
> two constructs have equivalent performance (the only place where CLtL
> addresses this is in the definition of 1+ and 1-, which says that they
> should have the same performance as calling + and - with a second
> argument of 1). Must they appear equivalent to the user if he ends up
> in the debugger in the middle of the construct?
I am really surprised by this line of argument. I am well aware that
it is difficult to define "equivalent" precisely. Nonetheless, both
CLtL and the Scheme Reports use this approach in a number of cases,
and I don't notice anyone flaming them for it.
CLtL is written in an informal style, so descriptions in terms of
equivalent code are acceptable there, but they aren't acceptable in an
ANSI standard. Users expect implementors to comply with the letter of a
standard, and lawsuits could arise over differing expectations about
equivalence.
The goals of Scheme are different from those of Common Lisp, so there
are different criteria for acceptability of the definitions. Scheme is
primarily an academic language, and the Scheme designers want the
language to be specified very rigorously, so they define the behavior of
a few primitives using denotational semantics, and then define the rest
of the language in terms of those primitives.
Rigorous definition is not the primary goal of Common Lisp
standardization (at one time we were planning on including a
denotational semantics in the standard, but no one on the committee who
was skilled enough had the time). Common Lisp's primary goals are to
support portable code and to allow high performance (hmm, aren't those
C's goals?).
In any case, I'm talking about using this technique in the same way
it's already used, not to specify even more.
It's used very little in the standard. Sometimes it's used in the
"Notes" section of an operator description, but these sections are not
part of the conformance criteria for an implementation.
CLtL doesn't say anything at all about what appears to the debugger,
nor does it specify exact expansions. Indeed, the whole point of
talking about equivalence is to avoid that.
Code walkers already have to make decisions about the extent to which
they preserve the original code.
In the few cases where we do describe equivalences, what I believe we
say is something like "returns the same value(s) as", in order to avoid
these "equivalence" problems. This is useful for simple things like (1+
x) being equivalent to (+ 1 x), but is harder when side effects and/or
binding contexts are involved; even inequivalent consing behavior can be
detected by using the ROOM function, and binding context differences are
apparent to closures that are returned or stored.
Another problem with specifying in terms of code is that we may carry
over unintended behavior (especially if a function referenced by the
equivalent code is later changed -- we'd need a good cross-reference
listing) or preclude some cases not handled by the "equivalent" code but
intended to be handled by the operator being defined. By specifying
each operator as independently as possible we have less trouble with
strange interactions. For instance, the description of SYMBOL-MACROLET
mentions that (setq <symbol-macro> <value>) is treated as if it were
(setf <symbol-macro> <value>), but it fails to mention PSETQ and
MULTIPLE-VALUE-SETQ (this was fixed at a recent meeting); this bug would
have been avoided had symbol macros been defined in terms of a general
notion of assignment rather than by reference to particular operators.
Moreover, we already have to define what the compiler can do. Most,
if not all, of the problems of equivalence come up there too. If
equivalence is really such a problem, why don't we hold up all Lisp
standards until we can define "equivalent" well enough to say what the
the compiler does?
Indeed, much of our effort has gone towards compiler issues. Not only
is code equivalence a problem, but so is data structure equivalence
(when code that is compiled to a file contains quoted or self-evaluating
data). We did the best we could to define this stuff.
No one is saying that we should hold up all Lisp standards for any of
this. We make trade-offs and compromises. Common Lisp trades off
specification precision for implementor flexibility.
> DO, on the other hand, is general enough that it's unlikely to map
> directly onto specialized machine instructions. Specifying it more
> precisely provides some benefit to the user without hindering the
> implementor much.
Specific cases of DO, however, are another matter. If compilers
handle the cases that result from DOTIMES well, they've solved two
problems at once. If you want to argue that DO is too hard to
optimize, I would disagree. C's "for" is not all that different from
DO, and C compilers seem to do pretty well.
C's "for" is just a control construct. DO is both a control construct
and also a lexical binding construct. The performance implications
arise from the lexical binding issues. Yes, a sufficiently smart
compiler could determine whether the iteration variable is assigned in
the body and compile differently, but we don't want to require such
smartness from compilers in order to get acceptable performance from
DOTIMES. The harder a language is to compile well, the fewer good
compilers there will be, and this doesn't serve the user community.
> > But it's hard to leave things intentionally vague when you specify with
> > code, unless you give all the different possibilities.
>
> That depends on just what flexibility you want to allow. Specifying
> some code and saying the behavior must be as if that expansion were
> used still allows a degree of flexibility. For example, I would
> expect the following expansion of the sample code would be allowed
> by most reasonable definitions:
>
> (dotimes (a 3) (progn (print :hello)
> (print :hello))) ==> (print :hello)
> (print :hello))
>
> But the standard can't specify equivalences in this way, it has to
> define things generally.
No kidding. That's why I said that sample expansion would be
*allowed by the definition*. I wasn't suggesting that it *was*
the definition or even part of it.
How can we make use of "allowed by the definition" in the standard?
Maybe you could provide an example of what you would like to see in the
standard?
We should make the specification more complete and precise unless
there is a good reason not to. I addressed performance above. Do you
really think Common Lisp would be worse off in performance relative to
C, for example, if DOTIMES were eliminated and programmers used DO?
Do you think the difference would be large enough (compared to CL
with DOTIMES) for anyone to care? I don't.
Maybe not. Someone at Symbolics thought it was important enough to put
some work into a highly-optimized version of DOTIMES.
> I agree that it started as a way to avoid warnings. But it doesn't
> work reliably even for that, given the variations allowed for DOTIMES.
>
> So Common Lisp isn't perfect; what else is new?
I see. So we shouldn't try to improve it?
We're past the deadline for making significant changes in the language.
We're trying to get the standard edited now. At this time we shouldn't
be making changes unless they fix real language bugs. I personally
don't feel that a style warning is sufficient justification for a change
to the semantics of DOTIMES.
> I would prefer a solution where the definition of DOTIMES didn't
> have to mention the IGNORE declaration explicitly.
>
> Why?
Because it's a patch. We should try for orthogonality rather than
ad hoc solutions to special cases.
I'm all for generality, orthogonality, and consistency. But X3J13 has
declared that these have lower priority than performance implications.
> The only complaint I've heard about DOTIMES is that it's unspecified
> whether an IGNORE declaration for the iteration variable is allowed.
I can turn some of the comments about assignment vs binding into
complaints if you'd like. Ditto the POP or not on page 178.
You can't validly complain that your program doesn't behave as you
expect when you do something CLtL specifically says not to do. You can
only detect binding context differences by using SETQ, and CLtL says
that SETQ'ing the iteration variable in DOTIMES is not portable, so that
complaint is already addressed.
You *can* complain that the language isn't specified to behave as you'd
wish it did. That's not the kind of complaint I was talking about,
though; the purpose of the CL standard is to allow portable Lisp code to
be written, and the CLtL description of DOTIMES appears to be sufficient
(except regarding warning messages): it says that if the body meets
certain constraints it will behave in a well-specified way.
In the language specification business one is always treading a fine
line between under-specifying and over-specifying. As I mentioned
above, it's a trade-off between implementation freedom and programmer
expectations. For instance, we made the description of NSUBSTITUTE more
precise (see the top of p.404 of CLtL2) because we believed that it is
more useful for programs to be able to depend on the results of
NSUBSTITUTE of shared list.
barmar
∂26-Jul-90 1356 Common-Lisp-mailer DOTIMES, part 2
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 26 Jul 90 13:55:54 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Thu 26 Jul 90 15:49:35-CDT
Return-Path: <barmar@Think.COM>
Received: from Sfs-Akv.Think.COM by mail.think.com; Thu, 26 Jul 90 16:49:27 -0400
Received: from OCCAM.THINK.COM by sfs-akv.think.com (4.0/Think-1.0C)
id AA07510; Thu, 26 Jul 90 16:49:25 EDT
Date: Thu, 26 Jul 90 16:49 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: DOTIMES, part 2
To: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Cc: Jon L White <jonl@lucid.com>, snicoud@atc.boeing.com, common-lisp@mcc.com
In-Reply-To: <7581.9007261632@subnode.aiai.ed.ac.uk>
Message-Id: <19900726204921.0.BARMAR@OCCAM.THINK.COM>
Date: Thu, 26 Jul 90 17:32:58 BST
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
> Most compilers would warn that PRINT-PACKAGE-AND-PLIST binds the
> variables VALUE and FUNCTION without using them. In order to suppress
> this warning you have to write:
>
> (defun print-package-and-plist (symbol)
> (with-symbol-variables symbol
> (declare (ignore value function))
> (format t "~S's package is ~A, its plist is ~S." symbol package plist)))
And is that IGNORE declaration incorrect? Or might a (correct)
compiler issue a warning saying the variable is used? My suggestion
was that macros should be written (not must be) so that such a
declaration would be correct.
That declaration would usually be correct. But there's no way for the
user of the macro to know whether it's correct or not. Perhaps the
macro uses VALUE internally for some reason. The macro's
documentation would have to say either "if <body> doesn't use some of
the variables bound by WITH-SYMBOL-VARIABLES it should explicitly
include IGNORE declarations," "<body> must not include IGNORE
declarations for the variables bound by WITH-SYMBOL-VARIABLES which are
not used in <body>," or a hybrid that says which variables the body must
supply IGNORE declarations for.
But I don't like the idea of having to include such statements in the
documentation of a macro; the hybrid variation is especially disturbing,
because it is so dependent upon the implementation of the macro, which
should be irrelevant to the caller and might change over time. An
IGNORABLE declaration that could be placed in the expansion would permit
the second form of the documentation, and something like Symbolics's
COMPILER:INVISIBLE-REFERENCES special form would make the first form
possible.
barmar
∂26-Jul-90 1521 Common-Lisp-mailer DOTIMES Variable
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 26 Jul 90 15:21:41 PDT
Received: from lucid.com by MCC.COM with TCP/SMTP; Thu 26 Jul 90 17:17:57-CDT
Received: from rose ([192.31.212.83]) by heavens-gate.lucid.com id AA00897g; Tue, 24 Jul 90 10:09:23 PDT
Received: by rose id AA02690g; Tue, 24 Jul 90 10:10:24 PDT
Date: Tue, 24 Jul 90 10:10:24 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <9007241710.AA02690@rose>
To: jbarnett@nrtc.northrop.com
Cc: Common-Lisp@mcc.com
In-Reply-To: Jeff Barnett's message of Tue, 24 Jul 90 09:55:58 -0700 <9007241701.AA00873@lucid.com>
Subject: DOTIMES Variable
Hm, one can use IGNORE as a variable, but I don't think there is any
``in lieu'' about it. Gimmicks are bad language design methodology.
It's what gave the world CALL-WITH-CURRENT-CONTINUATION. And consider:
(DEFUN IGNORE ...)
(FLET ((IGNORE ...)) ...)
(DEFCLASS IGNORE ...)
-rpg-
∂26-Jul-90 1540 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 26 Jul 90 15:40:15 PDT
Received: from lucid.com by MCC.COM with TCP/SMTP; Thu 26 Jul 90 17:20:28-CDT
Received: from rose ([192.31.212.83]) by heavens-gate.lucid.com id AA00549g; Tue, 24 Jul 90 09:27:52 PDT
Received: by rose id AA02431g; Tue, 24 Jul 90 09:28:52 PDT
Date: Tue, 24 Jul 90 09:28:52 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <9007241628.AA02431@rose>
To: kab@charon.MIT.EDU
Cc: jeff@aiai.edinburgh.ac.uk, jonl@lucid.com, snicoud@atc.boeing.com,
common-lisp@mcc.com
In-Reply-To: Kim A. Barrett's message of Tue, 24 Jul 90 11:35:06 EDT <9007241535.AA14270@charon.MIT.EDU>
Subject: DOTIMES
Using possible macro expansions to reason about language design is
poor methodology. DOTIMES should be specified and its implementation
choices outlined.
(let ((functions ()))
(dotimes (i 3)
(push #'(lambda () i) functions))
(mapcar #'funcall functions))
Using the first expansion, the result of this is (2 2 2), while using the
second expansion results in (2 1 0). I don't know of anything which would
imply that one or the other of these results is correct and the other
incorrect, though having two possible results for something like this is
pretty unpalatable.
For parallel Lisps, the second result is more intuitive, because
imagine this:
(dotimes (i 3)
(spawn #'(lambda ()...i...)))
It is likely that the body depends on the value of i at spawn time,
and it is unlikely that these processes wish to communicate through
the variable i. This interpretation and the opinion regarding which is
intuitive comes from *almost every* user of Qlisp. These users
bitterly complained about our incorrect definition of DOTIMES.
-rpg-
∂26-Jul-90 1826 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 26 Jul 90 18:26:30 PDT
Received: from RIVERSIDE.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Thu 26 Jul 90 20:21:19-CDT
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 478485; 26 Jul 90 21:18:18 EDT
Received: from KILIMANJARO.ILA.Dialnet.Symbolics.COM by F.ILA.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 42766; Thu 26-Jul-90 21:22:45 EDT
Date: Thu, 26 Jul 90 21:26 EDT
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Subject: DOTIMES
To: Richard P. Gabriel <rpg%lucid.com@Riverside.SCRC.Symbolics.COM>, kab%charon.mit.edu@Riverside.SCRC.Symbolics.COM
cc: jeff%aiai.edinburgh.ac.uk@Riverside.SCRC.Symbolics.COM, jonl%lucid.com@Riverside.SCRC.Symbolics.COM,
snicoud%atc.boeing.com@Riverside.SCRC.Symbolics.COM, common-lisp%mcc.com@Riverside.SCRC.Symbolics.COM
In-Reply-To: <9007241628.AA02431@rose>
Message-ID: <19900727012621.7.RWK@KILIMANJARO.ILA.Dialnet.Symbolics.COM>
Date: Tue, 24 Jul 90 09:28:52 PDT
From: Richard P. Gabriel <rpg@lucid.com>
Using possible macro expansions to reason about language design is
poor methodology. DOTIMES should be specified and its implementation
choices outlined.
I agree with this. While my first choice is for the assignment
semantics (reasoning below), I'm more concerned that it be
specified than that a particular semantics be chosen.
For parallel Lisps, the second result is more intuitive, because
imagine this:
(dotimes (i 3)
(spawn #'(lambda ()...i...)))
It is likely that the body depends on the value of i at spawn time,
and it is unlikely that these processes wish to communicate through
the variable i. This interpretation and the opinion regarding which is
intuitive comes from *almost every* user of Qlisp. These users
bitterly complained about our incorrect definition of DOTIMES.
This is a basic area of confusion/pitfalls in parallel Lisps, and
is a result of users making assumptions. Why would they not make
the same assumption about LOOP? Their argument hinges on *KNOWING*
what DOTIMES does with its variables; it is in no way explicit NOR
implied by any syntax, semantics, or (correctly read) documentation.
Having run into this confusion myself, I can sympathize with the
goal of avoiding this confusion. However, it's not so clear how
best to avoid it. In fact, I prefer the assignment semantics, because
I feel it allows statement of a simple rule. If the binding of
a variable is not clearly *INSIDE* of a loop, there's only one binding.
DO and LOOP behave this way; I don't think it's any more obviously
wrong for DOTIMES and DOLIST to also behave this way.
I think it's much MUCH better style for your QLISP users to write
(dotimes (i 3)
(let ((i i))
(spawn #'(lambda ()...i...))))
which makes THEIR intent clear, instead of depending on an invisible
feature of DOTIMES, even if DOTIMES is documented as behaving as they
expect. Just as we don't allow SETQing the I above, I think we should
regard the I as belonging to the DOTIMES. It's better to make your
intent clear, instead of depending on non-surface qualities of DOTIMES.
I believe this regardless of which way we define DOTIMES, but I note
that this policy is also compatible with the current "undefined"
situation.
Having DOTIMES use assignment syntax may be more efficient in some
implementations (although I don't really care about this). My real
concern is that it is a more fundamental interpretation; it's trivial
to add a LET if you want repeated binding semantics.
However, this is an old discussion, previously resolved as "leave it
undefined". (I think that was a mistake). The original issue was
quite distinct from this.
Variable semantics is a very fundamental aspect of the
language, and we have failed to specify an important part
of it. Traditionally, we have dismissed "style warnings"
as being an "environment" issue. However, in this case, I
do not think it should be so dismissed. Currently, we have
implementations of CL which vocally complain about opposite
usages. Having bogus style warnings go off in this way is
a serious problem for people porting code, because it
obscures legitimate problems. Bogus warnings are a serious
waste of time for porters of code, and they also make venders
of portable code look as if they are careless programmers.
I strongly feel that a well-written portable Common Lisp
program should compile with no warnings in any well-done
Common Lisp implementation. Otherwise, how is the user
of a portable program supposed to know if the warnings warn
of actual problems, or are just noise.
I strongly feel that X3J13 should firmly nail down under
what circumstances "unused variable" and "unused local function"
warnings may be issued. It is our failure to do so which is
at the heart of the current issue, and as a porter of code, it
has been a recurrent problem.
I also think that the kludge of mentioning the variable at
top level is not an acceptable solution.
I think the semantics of the IGNORE declaration should be firmed
up, and a policy stated about when it is OK to warn about an
IGNORE'd variable being used. (Does the SETQ implicit in DOTIMES
(assignment semantics) count as a use, if the result is never
looked at?)
There are also two capabilities which are missing, which have
been refered to as an IGNORABLE declaration and a
COMPILER:INVISIBLE-REFERENCES form, in BARMAR's message. I actually
think that both are needed. IGNORABLE states that it doesn't matter
if the user doesn't reference a variable. COMPILER:INVISIBLE-REFERENCES
(WITHOUT-REFERENCES ?) states that the user is *expected* to reference
a particular variable, and that style warnings are appropriate if he
does not.
I think both situations are common in macros, and that
because these issues are so close to the core of the
language semantics, this should be regarded as something
more than mere "style warnings". I wouldn't require
compilers and interpreters to issue the warnings in any
particular situation, but I do think we can and should
define the semantics of our variables sufficiently to
state when these warnings are and are not appropriate.
I'd also like to see all of these extended to local functions
in the same manner as the DYNAMIC-EXTENT declaration.
I would really like to see X3J13 act on these problems,
and I'd like to see this DOTIMES discussion focus more
on the exact form a proposal should take. Should the
COMPILER:INVISIBLE-REFERENCES form actually be a declaration
instead of a special form?
∂27-Jul-90 0845 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 08:45:31 PDT
Received: from NSFnet-Relay.AC.UK by MCC.COM with TCP/SMTP; Fri 27 Jul 90 10:32:34-CDT
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa10201; 27 Jul 90 16:15 BST
Date: Fri, 27 Jul 90 16:24:54 BST
Message-Id: <10783.9007271524@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: DOTIMES
To: Barry Margolin <barmar@think.com>
In-Reply-To: Barry Margolin's message of Thu, 26 Jul 90 16:03 EDT
Cc: Jon L White <jonl@lucid.com>, snicoud@atc.boeing.com, common-lisp@mcc.com
It is somewhat misleading to focus on the question of equivalence.
If we want to specify the semantics of some construct, we can do it
directly or indirectly via a rewriting in terms of more primitive
constructs. In the latter case, we say the actual implementation does
not have to be identical to the definition but has to have the same
semantics. In other words, this is just another way to get to the
semantics. Is is a way to reduce the overall effort both for the
person writing the specifications and for a person reading them.
This approach is used in the definitions of Scheme and Haskell
and no doubt in other places as well.
The problem of implementing or reasoning about something that has a
certain semantics is one we already have to solve. Giving the
semantics via more primitive constructs does not introduce a new
problem of determining whether the two patterns of code involved
are equivalent. One pattern is simply a means for getting to
the semantics of the other.
This is not to say an implementor who is implementing something like
DOTIMES as a macro will not ever ask whether the planned expansion is
equivalent to the code produced by a rewriting definition of DOTIMES.
But this is a way to ask whether the expansion has the right
semantics, which is what implementors always have to ask about macro
expansions. Far from making the task of devising a correct expansion
harder, a rewriting definition may make it easier.
However, we must also consider the task of determining whether
an expansion, perhaps devised by some other method, is correct.
I don't think this task is necessarily made harder either. If
the semantics of the more primitive constructs is well-defined,
it is presumably possible to determine what that semantics is
and then ask whether the expansion has that semantics. Getting
to the semantics via the more primitive does not necessarily
make the resulting semantics more complex. Nor does the extra
indirection necessarily make the task of determining the semantics
much more difficult.
In any case, if you do want to think in terms of equivalence, the
relevant sense of equivalent can be found by considering what the
semantics specifies. If it does not specify a particular efficiency
or appearance to the debugger, then the expansion doesn't have to
preserve those properties either.
This leaves the question of whether any important properties of
DOTIMES would be lost by this approach. I am open to the possibility
that someone will identify such a property. But I am not convinced
by the efficiency arguments given so far. Moreover, DOTIMES is
just one variety of integer loop, one where the variable starts at
zero. A good implementation will want to be able to optimize others
as well, and it has yet to be shown that any significant DOTIMES
optimization would be significantly more difficult if all such
loops were written, say, in terms of DO.
I will respond to some of Barmars specific points in another message.
-- Jeff
∂27-Jul-90 0925 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 09:25:32 PDT
Received: from NSFnet-Relay.AC.UK by MCC.COM with TCP/SMTP; Fri 27 Jul 90 11:24:02-CDT
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa11244; 27 Jul 90 17:11 BST
Date: Fri, 27 Jul 90 17:20:33 BST
Message-Id: <10992.9007271620@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: DOTIMES
To: Barry Margolin <barmar@think.com>
In-Reply-To: Barry Margolin's message of Thu, 26 Jul 90 16:03 EDT
Cc: Jon L White <jonl@lucid.com>, snicoud@atc.boeing.com, common-lisp@mcc.com
It turns out I agree with RPG when he writes:
Using possible macro expansions to reason about language design is
poor methodology. DOTIMES should be specified and its implementation
choices outlined.
I still think definition in terms of a rewriting is not inappropriate
for DOTIMES (and I would say this is different from using possible
expansions to reason about design), but I would also be happy with
another definition that is as good or (of course) better.
But the definition should let us provide a clean answer to the
questions about IGNORE and, if we decide they're important enough,
binding vs assignment, without having to deal with them as special
cases.
> CLtL is written in an informal style, so descriptions in terms of
> equivalent code are acceptable there, but they aren't acceptable in an
> ANSI standard. Users expect implementors to comply with the letter of a
> standard, and lawsuits could arise over differing expectations about
> equivalence.
I'm surprised that you say such descriptions are acceptable in an
informal definition "but ..." (implying they wouldn't be acceptable
otherwise, expecially in an ANSI standard) and then later say the
Scheme designers want their language (which is in part defined using
this technique) to be specified very rigorously. If it can be used
in a very rigorous definition, what's the problem?
Moreover, we are not talking of the general problem of code
equivalence but rather of whether some implementation (a macro
definition of DOTIMES, say) is correct in terms of some semantics
which happen to be given indirectly via a rewriting of DOTIMES in
terms of more primitive constructs.
The problem of whether an implementation is correct according to some
semantics may well be a very hard problem (maybe as hard, in a sense,
as the other one), but it's one we have to deal with anyway.
(I apologize for repeating points from my previous message.)
> Rigorous definition is not the primary goal of Common Lisp
> standardization (at one time we were planning on including a
> denotational semantics in the standard, but no one on the committee who
> was skilled enough had the time). Common Lisp's primary goals are to
> support portable code and to allow high performance (hmm, aren't those
> C's goals?).
Portability is enhanced by tighter definitions. If there's less scope
for implementations to differ, it's more likely that code that works
in one implementation will also work in others.
And as long as we're talking about C, the C standard (or at least
the May 13, 1988 draft, Doc. No. X3J11/88-090) defines "for" in
part by saying it's "equivalent" to some code involving "while".
(See section 3.6.5.3, page 76.)
> Another problem with specifying in terms of code is that we may carry
> over unintended behavior
I agree. For example, I think it is best not to define UNION by
giving a Lisp definition, because we don't want to pin down the
way structure will be shared between the arguments and the result.
However, the costs and benefits are different in different cases.
> By specifying each operator as independently as possible we have
> less trouble with strange interactions.
Except where we don't, as with DOTIMES and IGNORE.
Moreover, it is at least arguable that when too much is separate the
language is more complex and harder to learn.
> No one is saying that we should hold up all Lisp standards for any of
> this.
So we have agreed on an upper bound for the severity of the problem
of defining equivalence?
> C's "for" is just a control construct. DO is both a control construct
> and also a lexical binding construct. The performance implications
> arise from the lexical binding issues. Yes, a sufficiently smart
> compiler could determine whether the iteration variable is assigned in
> the body and compile differently, but we don't want to require such
> smartness from compilers in order to get acceptable performance from
> DOTIMES.
I don't think compilers have to be especially smart to notice
assignments. It's very common for compilers to do so.
> The harder a language is to compile well, the fewer good
> compilers there will be, and this doesn't serve the user community.
A good compiler might well prefer not to handle DOTIMES as a
special case.
> No kidding. That's why I said that sample expansion would be
> *allowed by the definition*. I wasn't suggesting that it *was*
> the definition or even part of it.
>
> How can we make use of "allowed by the definition" in the standard?
> Maybe you could provide an example of what you would like to see in the
> standard?
I didn't say, or at least didn't mean to say, "allowed by the
definition" would be part of the standard. I meant the definition
(the standard, if you will) would allow an implementation to
peform that particular loop unrolling. Was I really so unclear?
> Someone at Symbolics thought it was important enough to put
> some work into a highly-optimized version of DOTIMES.
And many, if not all, of those optimizations might still be possible.
> We're past the deadline for making significant changes in the language.
True.
> I'm all for generality, orthogonality, and consistency. But X3J13 has
> declared that these have lower priority than performance implications.
Which doesn't mean that a performance issue, no matter how trivial,
always wins.
> In the language specification business one is always treading a fine
> line between under-specifying and over-specifying.
Yes, and I happen to think X3J13 made the wrong decision *in this case*.
-- Jeff
∂27-Jul-90 1019 Common-Lisp-mailer destructuring our way around IGNORE
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 10:19:26 PDT
Received: from venera.isi.edu by MCC.COM with TCP/SMTP; Fri 27 Jul 90 12:18:23-CDT
Received: from hpai23.isi.edu by venera.isi.edu (5.61/5.61+local)
id <AA24028>; Fri, 27 Jul 90 10:15:18 -0700
Posted-Date: Fri, 27 Jul 90 13:17:53 EDT
Message-Id: <9007271718.AA01042@hpai23>
Received: by hpai23 (14.5/4.0.3-3)
id AA01042; Fri, 27 Jul 90 13:18:00 edt
To: common-lisp@mcc.com
From: goldman@venera.isi.edu
Subject: destructuring our way around IGNORE
Date: Fri, 27 Jul 90 13:17:53 EDT
Sender: goldman@venera.isi.edu
IGNORE declarations are necessary because of language constructs that
force a programmer to introduce a lexical variable that is not needed.
The three major sources are, I think,
1) in lambda lists, because a function is used in a role where it may
be passed arguments it does not need. [I include multiple-value-bind
in this category.]
2) multiple-value-setq, where the values that need to be consumed are
not just an initial sequence of those returned
3) macros (like DOTIMES), that require the provision of a variable
name that will be lexically bound in the expansion and permit
IGNORE declarations about it.
In all three cases, the form of DESTRUCTURING supported by CL's
LOOP macro would obviate the need for IGNORE declarations. More
important, it would make a useful capability more widely available.
It seems that only a historical account of CL can explain the
presence of DESTRUCTURING patterns in LOOP but not elsewhere.
This pattern language (different from that used in destructuring-bind
and macro lambda-lists) treats the symbol NIL not as a variable name,
but as a way for the programmer to avoid specifying a name for a
variable that is not needed.
[Actually, it is not stated whether NIL can be used as a
pattern itself or only as a pattern element. I assume that NIL
is allowed as a pattern.]
If this destructuring were allowed in the context above, I could write:
(defun arg1-is-integer (arg1 nil) ;;second arg is not consumed
(integerp arg1))
(defun CAR-is-integer ((car . nil))
;; first arg must be a CONS. Its CDR is not consumed
(integerp car))
(multiple-value-setq ((onea oneb) nil three) (producer-of-three-values))
(dotimes (nil n) (push 0 l))
A side note: the pattern language used in LOOPs destructuring
does NOT provide an analog of &whole. ML and HASKELL, functional
languages that use pattern-based destructuring heavily, do include
such a capability in the pattern language. It is very useful, and
would be in CL as well:
e.g., in a table of triples, apply foo to selected entries
(loop for (&whole entry a nil c) in table
when (< a c) do (foo entry))
Neil
∂27-Jul-90 1046 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 10:46:17 PDT
Received: from RIVERSIDE.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Fri 27 Jul 90 12:44:05-CDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 478803; 27 Jul 90 13:43:04 EDT
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 826332; 27 Jul 90 13:42:53 EDT
Date: Fri, 27 Jul 90 13:40 EDT
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DOTIMES
To: RWK@FUJI.ILA.Dialnet.Symbolics.COM, rpg%lucid.com@RIVERSIDE.SCRC.Symbolics.COM,
kab%charon.mit.edu@RIVERSIDE.SCRC.Symbolics.COM
cc: jeff%aiai.edinburgh.ac.uk@RIVERSIDE.SCRC.Symbolics.COM, jonl%lucid.com@RIVERSIDE.SCRC.Symbolics.COM,
snicoud%atc.boeing.com@RIVERSIDE.SCRC.Symbolics.COM, common-lisp%mcc.com@RIVERSIDE.SCRC.Symbolics.COM
In-Reply-To: <19900727012621.7.RWK@KILIMANJARO.ILA.Dialnet.Symbolics.COM>
Message-ID: <19900727174053.3.CASSELS@GROUSE.SCRC.Symbolics.COM>
Date: Thu, 26 Jul 90 21:26 EDT
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
COMPILER:INVISIBLE-REFERENCES
(WITHOUT-REFERENCES ?) states that the user is *expected* to reference
a particular variable, and that style warnings are appropriate if he
does not.
This is not correct. (COMPILER:INVISIBLE-REFERENCES <variables> . <body>)
tells the compiler that within <body>, references to <variables> are not
to be counted as "uses." So a (DECLARE (IGNORE ..)) variable will not
get a warning if it is referred to within <body>, and a variable which
is not referred to outside <body> will get an unused variable warning.
This is explained in the Genera documentation.
∂27-Jul-90 1102 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 11:02:10 PDT
Received: from Sun.COM by MCC.COM with TCP/SMTP; Fri 27 Jul 90 12:54:38-CDT
Received: from Eng.Sun.COM (exodus-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA11498; Fri, 27 Jul 90 10:53:55 PDT
Received: from clam.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA17007; Fri, 27 Jul 90 10:53:52 PDT
Received: by clam.Eng.Sun.COM (4.1/SMI-4.1)
id AA00589; Fri, 27 Jul 90 10:53:49 PDT
Date: Fri, 27 Jul 90 10:53:49 PDT
From: owner-clwin@Eng.Sun.COM (Cris Perdue)
Message-Id: <9007271753.AA00589@clam.Eng.Sun.COM>
To: barmar@think.com, jeff@aiai.edinburgh.ac.uk
Subject: Re: DOTIMES
Cc: common-lisp@mcc.com, jonl@lucid.com, snicoud@atc.boeing.com
Do any of you think it will be possible for someone to
produce a summary of the status of this discussion at
some point?
-Cris
∂27-Jul-90 1115 Common-Lisp-mailer Re: destructuring our way around IGNORE
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 11:15:09 PDT
Received: from spaulding (spaulding.Berkeley.EDU) by MCC.COM with TCP/SMTP; Fri 27 Jul 90 12:59:27-CDT
Message-Id: <2858090318-14242379@spaulding>
Sender: norvig@spaulding
Date: Fri, 27 Jul 90 10:58:38 PDT
Reply-To: norvig@teak.berkeley.edu
From: Peter Norvig <NORVIG@Teak.Berkeley.EDU>
To: goldman@venera.isi.edu
Cc: common-lisp@mcc.com
Subject: Re: destructuring our way around IGNORE
In-Reply-To: goldman@venera.isi.edu's msg of Fri, 27 Jul 90 13:17:53 EDT
>>> the form of DESTRUCTURING supported by CL's
>>> LOOP macro would obviate the need for IGNORE declarations.
Unfortunately, there are places where destructuring syntax would
be ambiguous, because there is another meaning for lists where
variables are expected. Consider:
(defun optional-CAR-is-integer (&optional (car nil))
(integerp car))
Does (car nil) mean that there is a variable named CAR with
default NIL, or does it mean that the optional argument must be
a two-element list, whose first element is destructured into CAR
and whose second is ignored? In:
(defmethod CAR-is-integer ((car cons))
(integerp car))
a similar ambiguity arises. One way to resolve the ambiguity
would be to require explicit syntax whenever destructuring is
used. Perhaps:
(defun CAR-is-integer ((:pattern (car . nil)))
;; first arg must be a CONS. Its CDR is not consumed
(integerp car))
(defun car-of-optional-arg-is-integer (&optional (:pattern (car nil)))
(integerp car))
(defun optional-arg-is-integer (&optional (car nil))
(integerp car))
(defmethod CAR-is-integer (((:pattern (car . nil)) cons))
(integerp car))
∂27-Jul-90 1128 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 11:28:25 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Fri 27 Jul 90 13:11:03-CDT
Return-Path: <barmar@Think.COM>
Received: from Sfs-Akv.Think.COM by mail.think.com; Fri, 27 Jul 90 14:10:57 -0400
Received: from OCCAM.THINK.COM by sfs-akv.think.com (4.0/Think-1.0C)
id AA08718; Fri, 27 Jul 90 14:10:53 EDT
Date: Fri, 27 Jul 90 14:10 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: DOTIMES
To: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Cc: Jon L White <jonl@lucid.com>, snicoud@atc.boeing.com, common-lisp@mcc.com
In-Reply-To: <10992.9007271620@subnode.aiai.ed.ac.uk>
Message-Id: <19900727181042.9.BARMAR@OCCAM.THINK.COM>
Date: Fri, 27 Jul 90 17:20:33 BST
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
But the definition should let us provide a clean answer to the
questions about IGNORE and, if we decide they're important enough,
binding vs assignment, without having to deal with them as special
cases.
> CLtL is written in an informal style, so descriptions in terms of
> equivalent code are acceptable there, but they aren't acceptable in an
> ANSI standard. Users expect implementors to comply with the letter of a
> standard, and lawsuits could arise over differing expectations about
> equivalence.
I'm surprised that you say such descriptions are acceptable in an
informal definition "but ..." (implying they wouldn't be acceptable
otherwise, expecially in an ANSI standard) and then later say the
Scheme designers want their language (which is in part defined using
this technique) to be specified very rigorously. If it can be used
in a very rigorous definition, what's the problem?
I interpret many of CLtL's equivalences as descriptive, not
proscriptive. They are examples of how one might implement the
operator. The Scheme report's equivalences, however, are definitions.
The format of the ANSI standard will make it clear what parts are
requirements on implementations and what parts are notes and examples,
which are not binding.
The Common Lisp standard needs to be more rigorous than CLtL, but I
think the Scheme report is even more rigorous than we want to be with
the CL standard. CL is designed to give more leeway to the implementor
than Scheme does. Scheme is designed for use by computer science
researchers to experiment with language features, so it is extremely
important that program-analysis tools be able to reason about the
behavior of programs. For Common Lisp a denotational semantics would be
nice; for Scheme it's a virtual necessity.
> Rigorous definition is not the primary goal of Common Lisp
> standardization (at one time we were planning on including a
> denotational semantics in the standard, but no one on the committee who
> was skilled enough had the time). Common Lisp's primary goals are to
> support portable code and to allow high performance (hmm, aren't those
> C's goals?).
Portability is enhanced by tighter definitions. If there's less scope
for implementations to differ, it's more likely that code that works
in one implementation will also work in others.
Portability can be enhanced in two ways: restrictions on implementors
and restrictions on the allowed programs.
Note also that I mentioned TWO primary goals. Portability is one, and
high performance is the other. Common Lisp frequently leaves cases
unspecified in order to achieve the latter goal.
And as long as we're talking about C, the C standard (or at least
the May 13, 1988 draft, Doc. No. X3J11/88-090) defines "for" in
part by saying it's "equivalent" to some code involving "while".
(See section 3.6.5.3, page 76.)
An example where C makes the same kind of trade-off I've been talking
about is its integer division and modulus operators. If the arguments
have different signs and the denominator doesn't divide the numerator
exactly the precise results of these two operators aren't defined
(division is permitted to truncate either towards 0 or negative
infinity), except that the two operators are related by an equation.
This is specified this way just so that C compilers can translate
high-level division directly into the machine's native division.
> Another problem with specifying in terms of code is that we may carry
> over unintended behavior
I agree. For example, I think it is best not to define UNION by
giving a Lisp definition, because we don't want to pin down the
way structure will be shared between the arguments and the result.
However, the costs and benefits are different in different cases.
Good, I'm glad to see that you're not arguing that everything possible
be defined this way. I wasn't sure to what extent you intended this be
done.
As evidence that I'm not totally against definition in terms of code,
see the description of NCONC in CLtL2 -- I wrote the new stuff that uses
the pattern matching.
> By specifying each operator as independently as possible we have
> less trouble with strange interactions.
Except where we don't, as with DOTIMES and IGNORE.
Actually, I think DOTIMES and IGNORE are susceptible to this problem.
Suppose we had defined
(dotimes (<var> <count-form> <result-form>)
<body>)
as being equivalent to
(do* ((count <count-form>)
(<var> 0 (1+ <var>)))
((>= <var> count)
<result-form>)
<body>)
so long as <body> contains no assignments to <var> and no reference to a
variable named COUNT.
This would certainly specify whether (declare (ignore <var>)) is allowed
(it wouldn't be). But would that have been our intention when we
defined that equivalence (I think not)? The above definition presumably
prohibits DOTIMES from complaining that <var> is unused; but since no
one ever thought of implementing such a warning until last year I doubt
this prohibition would have been intentional.
Common Lisp also doesn't have all the primitives necessary for
definitions of many things in terms of code. For instance, suppose we
wanted to define the behavior of the generic arithmetic routines this
way. We would need non-generic arithmetic routines for it to call.
> In the language specification business one is always treading a fine
> line between under-specifying and over-specifying.
Yes, and I happen to think X3J13 made the wrong decision *in this case*.
I don't think X3J13 actually *made* this decision. X3J13 didn't write
CLtL, and we simply didn't change DOTIMES. As far as I know there was
never a proposal to define DOTIMES more precisely, so we never decided
not to.
barmar
∂27-Jul-90 1150 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 11:50:43 PDT
Received: from RIVERSIDE.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Fri 27 Jul 90 13:48:07-CDT
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 478874; 27 Jul 90 14:46:17 EDT
Received: from KILIMANJARO.ILA.Dialnet.Symbolics.COM by F.ILA.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 42877; Fri 27-Jul-90 14:50:43 EDT
Date: Fri, 27 Jul 90 14:54 EDT
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Subject: Re: DOTIMES
To: Barry Margolin <barmar%think.com@Riverside.SCRC.Symbolics.COM>, Jeff Dalton <jeff%aiai.edinburgh.ac.uk@Riverside.SCRC.Symbolics.COM>
cc: Jon L White <jonl%lucid.com@Riverside.SCRC.Symbolics.COM>, snicoud%atc.boeing.com@Riverside.SCRC.Symbolics.COM,
common-lisp%mcc.com@Riverside.SCRC.Symbolics.COM
In-Reply-To: <19900726200357.9.BARMAR@OCCAM.THINK.COM>
Message-ID: <19900727185428.1.RWK@KILIMANJARO.ILA.Dialnet.Symbolics.COM>
Date: Thu, 26 Jul 90 16:03 EDT
From: Barry Margolin <barmar@think.com>
We're past the deadline for making significant changes in the language.
We're trying to get the standard edited now. At this time we shouldn't
be making changes unless they fix real language bugs. I personally
don't feel that a style warning is sufficient justification for a change
to the semantics of DOTIMES.
I feel that the style warnings *ARE* an important enough
issue, because these style warnings are by default dictating
the variable semantics, but in a manner inconsistent from
implementation to implementation.
However, I don't think that changing the definition of DOTIMES
is the way to resolve the issue. I think whether DOTIMES vars
are bound or assigned is a completely separate issue, and we
should instead address the behaviour of IGNORE and related
issues.
Assuming we specify the semantics of IGNORE and friends properly,
for DOTIMES and DOLIST, what this implies is specifying whether
these macros "use" their variables or not. (I vote for "do not").
∂27-Jul-90 1414 Common-Lisp-mailer destructuring our way around IGNORE
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 14:14:01 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Fri 27 Jul 90 16:02:41-CDT
Return-Path: <barmar@Think.COM>
Received: from Sfs-Akv.Think.COM by mail.think.com; Fri, 27 Jul 90 17:02:37 -0400
Received: from OCCAM.THINK.COM by sfs-akv.think.com (4.0/Think-1.0C)
id AA08926; Fri, 27 Jul 90 17:02:34 EDT
Date: Fri, 27 Jul 90 17:02 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: destructuring our way around IGNORE
To: goldman@venera.isi.edu
Cc: common-lisp@mcc.com
In-Reply-To: <9007271718.AA01042@hpai23>
Message-Id: <19900727210229.2.BARMAR@OCCAM.THINK.COM>
I considered suggesting that we extend all the binding forms to permit
NIL to indicate an ignored variable. However, a feature of the IGNORE
declaration that is lost if this is done is the name of the ignored
argument, which is useful for self-documentation purposes (and most Lisp
environments also provide a function to look up the argument list of a
function).
barmar
∂27-Jul-90 1556 Common-Lisp-mailer PLEASE REMOVE ME
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 15:56:03 PDT
Received: from Xerox.COM by MCC.COM with TCP/SMTP; Fri 27 Jul 90 17:45:46-CDT
Received: from Salvador.ms by ArpaGateway.ms ; 27 JUL 90 15:32:48 PDT
Sender: "Monica_J_General.Henr801B"@Xerox.COM
Date: 27 Jul 90 12:58:35 PDT (Friday)
Subject: PLEASE REMOVE ME
From: "Monica_J_General.Henr801B"@Xerox.COM
To: common-lisp@mcc.COM
cc: "Monica_J_General.Henr801B"@Xerox.COM
In-Reply-to: goldman%venera.isi:EDU:Xerox's message of 27-July-90 (Friday)
14:04:52 EDT
Message-ID: <900727-153248-6328@Xerox>
FOR SOME REASON I HAVE BEEN RECIEVING MAIL NOTES FROM THIS DL.
I DON'T THINK I SHOULD BE GETTING THESE NOTES.
COULD SOMEONE HELP ME.
THANK YOU.
MONICA GENERAL
∂27-Jul-90 1750 Common-Lisp-mailer hash table iterators
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 17:50:38 PDT
Received: from venera.isi.edu by MCC.COM with TCP/SMTP; Fri 27 Jul 90 19:48:15-CDT
Received: from hpai23.isi.edu by venera.isi.edu (5.61/5.61+local)
id <AA12304>; Fri, 27 Jul 90 17:45:11 -0700
Posted-Date: Fri, 27 Jul 90 20:47:50 EDT
Message-Id: <9007280047.AA02968@hpai23>
Received: by hpai23 (14.5/4.0.3-3)
id AA02968; Fri, 27 Jul 90 20:47:56 edt
To: common-lisp@mcc.com
Subject: hash table iterators
Date: Fri, 27 Jul 90 20:47:50 EDT
From: Don Cohen <donc@venera.isi.edu>
CLtL2 describes with-hash-table-iterator (also package iterator and
who knows what other similar things). I'm happy to see maphash
opened up a little, but the fact that these define dynamic extent
functions (or actually macros) is very disappointing. Why couldn't
we have the following instead?
(hashtable-generator ht) => a closure which, on subsequent calls
returns what the iterator macro would have returned.
As is the case with maphash and other iteration constructs, it is
an error to change a table (setf of gethash, clrhash, or remhash)
between a call to hashtable-generator and the last use of its result.
This seems clearly more general, and very easy to provide.
∂27-Jul-90 1805 Common-Lisp-mailer Re: hash table iterators
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 18:05:47 PDT
Received: from lucid.com by MCC.COM with TCP/SMTP; Fri 27 Jul 90 20:04:29-CDT
Received: from challenger ([192.31.212.17]) by heavens-gate.lucid.com id AA09476g; Fri, 27 Jul 90 18:01:04 PDT
Received: by challenger id AA03031g; Fri, 27 Jul 90 18:04:48 PDT
Date: Fri, 27 Jul 90 18:04:48 PDT
Message-Id: <9007280104.AA03031@challenger>
From: Jamie Zawinski <jwz@lucid.com>
Sender: jwz@lucid.com
To: donc@venera.isi.edu
Cc: common-lisp@mcc.com
In-Reply-To: Don Cohen's message of Fri, 27 Jul 90 20:47:50 EDT <9007280047.AA02968@hpai23>
Subject: Re: hash table iterators
Don Cohen writes:
> Why couldn't we have the following instead? (hashtable-generator ht) => a
> closure which, on subsequent calls returns what the iterator macro would have
> returned. As is the case with maphash and other iteration constructs, it is
> an error to change a table (setf of gethash, clrhash, or remhash) between a
> call to hashtable-generator and the last use of its result.
Seems like a really easy way to shaft yourself - what if you cons up one of
these continuations and then lose it. Now you've got this locked hash table,
and you're going to have to grovel around until you find a way to smash the
lock. This is the only reason I can think of that with-hash-table-iterator
would be defined to have dynamic extent - either the system must give up on
doing hash-table locking properly, or it's really easy to indefinitely lock a
table.
-- Jamie
∂27-Jul-90 1843 Common-Lisp-mailer Re: hash table iterators
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 18:43:25 PDT
Received: from venera.isi.edu by MCC.COM with TCP/SMTP; Fri 27 Jul 90 20:41:58-CDT
Received: from hpai23.isi.edu by venera.isi.edu (5.61/5.61+local)
id <AA00481>; Fri, 27 Jul 90 18:41:55 -0700
Posted-Date: Fri, 27 Jul 90 21:16:54 EDT
Message-Id: <9007280116.AA03150@hpai23>
Received: by hpai23 (14.5/4.0.3-3)
id AA03150; Fri, 27 Jul 90 21:16:58 edt
To: jwz@lucid.com
Cc: common-lisp@mcc.com
Subject: Re: hash table iterators
Date: Fri, 27 Jul 90 21:16:54 EDT
From: Don Cohen <donc@venera.isi.edu>
jwz writes:
... Now you've got this locked hash table, ...
Who said that hashtables have to be locked?
∂27-Jul-90 2034 Common-Lisp-mailer Re: hash table iterators
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 20:34:25 PDT
Received: from lucid.com by MCC.COM with TCP/SMTP; Fri 27 Jul 90 22:31:53-CDT
Received: from challenger ([192.31.212.17]) by heavens-gate.lucid.com id AA10604g; Fri, 27 Jul 90 20:28:32 PDT
Received: by challenger id AA03231g; Fri, 27 Jul 90 20:32:18 PDT
Date: Fri, 27 Jul 90 20:32:18 PDT
Message-Id: <9007280332.AA03231@challenger>
From: Jamie Zawinski <jwz@lucid.com>
Sender: jwz@lucid.com
To: donc@venera.isi.edu
Cc: common-lisp@mcc.com
In-Reply-To: Don Cohen's message of Fri, 27 Jul 90 21:16:54 EDT <9007280116.AA03150@hpai23>
Subject: Re: hash table iterators
Don Cohen writes:
> jwz writes:
> ... Now you've got this locked hash table, ...
> Who said that hashtables have to be locked?
Maybe I'm misremembering, but doesn't CLtL2 say that during the scope of these
hash-table iterators, it's not legal to add new items to the hash table? If
this is true, then failing to finalize the closure you proposed would leave
the table in a very bad state.
-- Jamie
PS: when I mail to common-lisp@mcc.com I get a heroic number of bounce
messages. I realize that this list is not centralized, but it would be really
great if the various relay site maintainers would send out a test message to
their members and nuke the ones that bounce...
∂27-Jul-90 2056 Common-Lisp-mailer hash table iterators
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 27 Jul 90 20:55:59 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Fri 27 Jul 90 22:53:17-CDT
Return-Path: <barmar@Think.COM>
Received: from Gandalf.Think.COM by mail.think.com; Fri, 27 Jul 90 23:53:12 -0400
Received: by gandalf.think.com (4.0/Think-1.0C)
id AA23887; Fri, 27 Jul 90 23:50:37 EDT
Date: Fri, 27 Jul 90 23:50:37 EDT
From: barmar@Think.COM
Message-Id: <9007280350.AA23887@gandalf.think.com>
To: donc@venera.isi.edu
Cc: common-lisp@mcc.com
In-Reply-To: <9007280047.AA02968@hpai23>
Subject: hash table iterators
Date: Fri, 27 Jul 90 20:47:50 EDT
From: Don Cohen <donc@venera.isi.edu>
CLtL2 describes with-hash-table-iterator (also package iterator and
who knows what other similar things). I'm happy to see maphash
opened up a little, but the fact that these define dynamic extent
functions (or actually macros) is very disappointing. Why couldn't
we have the following instead?
(hashtable-generator ht) => a closure which, on subsequent calls
returns what the iterator macro would have returned.
As is the case with maphash and other iteration constructs, it is
an error to change a table (setf of gethash, clrhash, or remhash)
between a call to hashtable-generator and the last use of its result.
This seems clearly more general, and very easy to provide.
The implementation may need to perform actions upon entry and exit of an
iteration over these objects. For instance, Lisps with multiple threads
might need to grab and release locks.
Also, we just wanted to codify the mechanism already in use in
implementations of LOOP, rather than define something new, so that portable
implementations of OSS package and hash table iteration could be written
(since we decided not to adopt OSS into the language).
∂28-Jul-90 1601 Common-Lisp-mailer destructuring our way around IGNORE
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 28 Jul 90 16:01:41 PDT
Received: from lucid.com by MCC.COM with TCP/SMTP; Sat 28 Jul 90 17:48:07-CDT
Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA15862g; Sat, 28 Jul 90 14:47:34 PDT
Site:
Received: by ptl-club id AA14026g; Sat, 28 Jul 90 14:51:00 PDT
Date: Sat, 28 Jul 90 14:51:00 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <9007282151.AA14026@ptl-club>
To: goldman@venera.isi.edu
Cc: common-lisp@mcc.com
In-Reply-To: goldman@venera.isi.edu's message of Fri, 27 Jul 90 13:17:53 EDT <9007271718.AA01042@hpai23>
Subject: destructuring our way around IGNORE
re: e.g., in a table of triples, apply foo to selected entries
(loop for (&whole entry a nil c) in table
when (< a c) do (foo entry))
I often find myself doing the slightly-less-than optimal:
(loop for entry in table
as (a nil c) = entry
when (< a c) do (foo entry))
-- JonL --
∂28-Jul-90 1753 Common-Lisp-mailer Re: hash table iterators
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 28 Jul 90 17:53:43 PDT
Received: from venera.isi.edu by MCC.COM with TCP/SMTP; Sat 28 Jul 90 19:48:28-CDT
Received: from hpai23.isi.edu by venera.isi.edu (5.61/5.61+local)
id <AA24313>; Sat, 28 Jul 90 17:45:23 -0700
Posted-Date: Sat, 28 Jul 90 20:48:02 EDT
Message-Id: <9007290048.AA06726@hpai23>
Received: by hpai23 (14.5/4.0.3-3)
id AA06726; Sat, 28 Jul 90 20:48:06 edt
To: jwz@lucid.com, barmar@think.com, common-lisp@mcc.com
Subject: Re: hash table iterators
Date: Sat, 28 Jul 90 20:48:02 EDT
From: Don Cohen <donc@venera.isi.edu>
from jwz:
... now you've got this locked hash table, ...
who said that hashtables have to be locked?
during the scope of these hash-table iterators, it's not legal to
add new items to the hash table?
In this case "it's not legal" means that it's the programmer's responsibility
not to do it. It's not the lisp system's responsibility. I agree that I'll
have to be careful, just like I have to be careful all over the place to avoid
things that are "an error".
re: PS: when I mail to common-lisp@mcc.com I get a heroic number of bounce ...
I second, third and fourth this suggestion (now that I'm on my 3rd msg!)
from barmar:
The implementation may need to perform actions upon entry and exit of an
iteration over these objects. For instance, Lisps with multiple threads
might need to grab and release locks.
I realize that multiple processes (and gc) present various problems, but
that's true in all sorts of other data structures, such as lists and
I don't know of any lisps that protect you there, e.g.,
(incf x) seems just as much an atomic operation as (setf (gethash ..))
and yet there's no code that prevents two processes from interfering with
each other try to do incf's.
As for the special case of hashtables, even if you want to prevent one process
doing a gethash while another does a (setf (gethash ...)), that's still not
a good reason to lock a hashtable for an entire iteration, either a maphash
or one of my type. Avoiding that sort of interference is the programmer's
job according to CLtL2.
In my proposal the system would indeed have to make adjustments to the closure
objects as it reorganized hashtables, e.g., during GC, but that's nothing new.
However, my closures would be GC'd when they were no longer referenced, rather
than having dynamic extent as is the case for with-hash-table-iterator.
Also, we just wanted to codify the mechanism already in use in
implementations of LOOP, rather than define something new, so that portable
implementations of OSS package and hash table iteration could be written
(since we decided not to adopt OSS into the language).
Obviously my mechanism allows you to do this as well. It also allows you to
do stuff (like continuations) that you simply cannot do now. It's pretty easy
to create the kind of generator function I want for almost all other data
structures. I'm prevented from doing it for hashtables (and a few related
things) for no good reason that I can see.
∂28-Jul-90 2218 Common-Lisp-mailer hash table iterators
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 28 Jul 90 22:18:06 PDT
Received: from lucid.com by MCC.COM with TCP/SMTP; Sun 29 Jul 90 00:09:36-CDT
Received: from ptl-club ([192.31.212.51]) by heavens-gate.lucid.com id AA17933g; Sat, 28 Jul 90 22:05:58 PDT
Received: by ptl-club id AA14358g; Sat, 28 Jul 90 22:09:25 PDT
Date: Sat, 28 Jul 90 22:09:25 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <9007290509.AA14358@ptl-club>
To: donc@venera.isi.edu
Cc: jwz@lucid.com, barmar@think.com, common-lisp@mcc.com, jonl@lucid.com
In-Reply-To: Don Cohen's message of Sat, 28 Jul 90 20:48:02 EDT <9007290048.AA06726@hpai23>
Subject: hash table iterators
re: Obviously my mechanism allows you to do this as well. It also allows you
to do stuff (like continuations) that you simply cannot do now. It's
pretty easy to create the kind of generator function I want for almost all
other data structures. I'm prevented from doing it for hashtables (and a
few related things) for no good reason that I can see.
How about this reason? There is no inherent ordering to the objects
in a hash-table; thus the ordering presented by MAPHASH and
WITH-HASHTABLE-ITERATOR is arbitrary. But every indefinite-extent
function (as per your suggestion) that is a hash-table sequence
generator will implement some ordering. Now -- here's the rub --
that ordering must be both complete and non-duplicating; and to
implement those requirements in a way that isn't constrained by the
dynamic extent of the iteration would require either excessive
consing, or super-normal compiler techniques, or both.
I remember this matter being discussed briefly in X3J13 discussions,
but there wasn't strong enough interest to overturn the decision.
I think basically the implementational constraints came from the
details of the Symbolics current implementation and a proposed variant
of the Lucid implementation of MAPHASH etc.
By the bye, I've removed my name from the Common-Lisp@MCC redistribution.
Between trying to ignore the dotimes discussion, and rebound from the
bounced mail, enough is enough already.
-- JonL --
∂29-Jul-90 1011 Common-Lisp-mailer hash table iterators ordering, etc
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 29 Jul 90 10:11:18 PDT
Received: from vaxa.isi.edu by MCC.COM with TCP/SMTP; Sun 29 Jul 90 11:55:51-CDT
Posted-Date: Sun, 29 Jul 90 09:52:19 PDT
Message-Id: <9007291652.AA18674@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
id AA18674; Sun, 29 Jul 90 09:52:22 -0700
To: jonl@lucid.com
Cc: jwz@lucid.com, barmar@think.com, common-lisp@mcc.com
Subject: hash table iterators ordering, etc
Date: Sun, 29 Jul 90 09:52:19 PDT
From: Don Cohen <donc@vaxa.isi.edu>
from jonl:
How about this reason? There is no inherent ordering...
... must be both complete and non-duplicating; and to
implement those requirements in a way that isn't constrained by the
dynamic extent of the iteration would require either excessive
consing, or super-normal compiler techniques, or both.
I don't see this. In a simple world where addresses of objects never
changed there would be no problem at all - just let the closure keep
an index into the hashtable and on each pulse update it to the index
of the next thing. The problem arises when the GC starts moving things
and they have to be rehashed. This doesn't seem off hand like anything
related to dynamic extent. How does symbolics solve the problem for
maphash when things get moved? (For that matter, how do you know what
has to be rehashed? Does EQUAL hashing make any use of addresses?
It ought to for the same reasons as EQ hashing, but the problem of
rehashing would then seem severe!)
I think basically the implementational constraints came from the
details of the Symbolics current implementation and a proposed variant
of the Lucid implementation of MAPHASH etc.
This I find much more believable, but not a good reason to prevent me
from doing something perfectly reasonable.
∂29-Jul-90 1142 Common-Lisp-mailer Re: hash table iterators ordering, etc
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 29 Jul 90 11:42:44 PDT
Received: from lucid.com by MCC.COM with TCP/SMTP; Sun 29 Jul 90 13:21:31-CDT
Received: from challenger ([192.31.212.17]) by heavens-gate.lucid.com id AA20826g; Sun, 29 Jul 90 11:17:39 PDT
Received: by challenger id AA05125g; Sun, 29 Jul 90 11:21:27 PDT
Date: Sun, 29 Jul 90 11:21:27 PDT
Message-Id: <9007291821.AA05125@challenger>
From: Jamie Zawinski <jwz@lucid.com>
Sender: jwz@lucid.com
To: donc@vaxa.isi.edu
Cc: jonl@lucid.com, barmar@think.com, common-lisp@mcc.com
In-Reply-To: Don Cohen's message of Sun, 29 Jul 90 09:52:19 PDT <9007291652.AA18674@vaxa.isi.edu>
Subject: Re: hash table iterators ordering, etc
> In a simple world where addresses of objects never changed there would be no
> problem at all - just let the closure keep an index into the hashtable and on
> each pulse update it to the index of the next thing. The problem arises when
> the GC starts moving things and they have to be rehashed.
Rehashing isn't a result of GC, it's a result of adding or deleting things
from the table. Suppose you cons up one of these closures pointing at a hash
table whose hash vector is 20 long; each call to it returns the contents of
the next hash bucket. You call it five times, and then add ten more things to
the table. This triggers a rehash - the hash table vector is grown, which
probably means it is moved (but I don't think that's important). The
important thing is that the contents of the new array could be completely
different. The only way to be complete and non-duplicating is to keep a copy
of the original contents (and order) of the hash table, and to realize what
new things have been added since then. This is totally impractical. It's on
the order of
(defun make-hash-table-stream (ht)
(let ((contents '()))
(maphash #'(lambda (k v) (push (cons k v) contents)) ht)
#'(lambda ()
(let ((c (pop contents)))
(values (car c) (cdr c))))))
Of course if you're willing to live with the constraint that calling the
has-table closure after having added or deleted something from the table
"is an error" then this isn't a problem. I think that's a little foul,
though.
BTW, in this case "is an error" could actually signal, and not just silently
screw up. If hash tables had a "tick" on them that was incremented at each
rehash, the closure could check this and signal an error if it had changed.
> How does symbolics solve the problem for maphash when things get moved?
What problem? The only way I could see a problem is if GC decided to move
the table in the middle of a maphash, which a simple locking scheme would fix.
> (For that matter, how do you know what has to be rehashed? Does EQUAL hashing
> make any use of addresses? It ought to for the same reasons as EQ hashing,
> but the problem of rehashing would then seem severe!)
Using addresses as hash codes is probably not legal - from CLtL1 (since I
don't have a copy of 2 around): "SXHASH computes a hash code for an object ...
The manner in which the has code is computed is implementation dependant, but
is independant of the particular `incarnation' or `core image'. Hash values
produced by SXHASH may be written out to files, for example, and meaningfully
read in again into an instance of the same implementation." Now I guess hash
tables don't actually have to use SXHASH to compute their hash codes, but it
seems likely that they would.
-- Jamie "38 bounces and counting" Zawinski
∂29-Jul-90 2018 Common-Lisp-mailer Update on Third CLOS Users and Implementors Workshop
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 29 Jul 90 20:18:10 PDT
Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Sun 29 Jul 90 14:29:47-CDT
Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 29 Jul 90 12:27:46 PDT
Received: from hplap.hpl.hp.com by hplms2.hpl.hp.com with SMTP
(15.11.1.3/15.5+IOS 3.20) id AA10633; Sun, 29 Jul 90 12:29:17 pdt
Received: from localhost by hplap.hpl.hp.com with SMTP
(15.11/15.5+IOS 3.14) id AA01587; Sun, 29 Jul 90 12:28:45 pdt
Message-Id: <9007291928.AA01587@hplap.hpl.hp.com>
To: commonloops.pa@xerox.com, common-lisp-object-system@sail.stanford.edu,
common-lisp@sail.stanford.edu
Subject: Update on Third CLOS Users and Implementors Workshop
X-Mailer: mh6.5
Date: Sun, 29 Jul 90 12:28:36 PDT
From: Andreas Paepcke <paepcke@hplap.hpl.hp.com>
I don't know how well the OOPSLA information dissemination machinery works.
So here is a repeat of the original call for participation in this year's
CLOS Workshop and a bit of update information: The day of the Workshop is
now set: The Games will commence on
Sunday, Oct. 21 '90 in the context of OOPSLA in Ottawa
I attach the original summons of the gladiators for your convenience.
Several of you have asked for an extension, partly due to AAAI. Please let
me know if you have had trouble with something like this as well.
For those of you who are interested in attending, please let me know your
expectations to help me plan the agenda details successfully. Which
information do you minimally want to take home with you? Would you like to
hear a particular person speak? Do you like presentations to guide
discussions or are you into free-style wrestling? (Be warned that there
will be metal detectors at the door). Do you have particular discussion
topics on your mind? Please drop me a note.
Looking forward,
Andreas
;;;;;;;;;;;;;;;;;;;; Original Call for Participation ;;;;;;;;;;;;;;;
Third CLOS Users and Implementor's Workshop 1990
`Now What?'
The first CLOS Workshop in 1988 was organized to bring the CLOS community
together and to make known which areas were being addressed in university
and industrial centers. The 1989 Workshop was dominated by introspection,
the examination of issues important at the time.
CLOS has now matured to a point where it is time to take stock and to
understand what should happen next. One goal will need to be the projection
of CLOS out into the community. An obviously important component of this is
the organization and publication of projects that use CLOS. A second
component must be a clarification of what is still missing and how CLOS
should be improved or completed. A third component, finally, is reflection
on how the language has advanced the state of the art or has a potential for
doing this.
This year's Workshop is to serve a dual purpose. The first is to let us
touch bases to learn what has been happening in the CLOS community and what
is to be done next. The second is to provide material and direction for the
"CLOS Report", a publication that will highlight the many facets of the
language and its history. This will be a collection of full length papers
to be published some time after the Workshop. We hope that our meeting and
its associated short papers can draw attention to contributions that should
make their way into such a collection.
The format of the Workshop reflects these two goals. We will try to divide
the day into three units. The first will be a critical look back to where
we have been. We will try to identify, collect and evaluate decisions we
made to ensure that we learn all we can from CLOS' rich, hectic history.
This could involve an analysis of what worked well and what went wrong. It
would also be useful simply to spell out which constraints led to
particular decisions and whether our resolutions were meaningful.
The second unit will be an attempt to compile a representative list of
projects which use CLOS for various purposes. Our goal will be to assemble
a portfolio of projects that illuminate different aspects of the language.
These could, for instance, include the metaobject protocol, CLOS' approach
to inheritance, method combination or other issues. Emphasis will be on
broad coverage.
The third unit, finally, will attempt to produce a roadmap, or at least a
series of mile stones to identify what needs to happen during the next two
or three years and how it could be achieved. The hope is that this unit
will profit from the review and survey of the first two units.
To get units one and three started we plan to invite two speakers each, who
will present opposing, controversial views of ten minutes each. Afterwards,
we will turn to plenum discussion.
The Workshop logistics will follow OOPSLA ACM guidelines. Attendance will
have to be limited to 30 contributors. Each contributor will need to submit
a short position paper of two to five pages. Each paper should be
classified to indicate which of the three units the paper addresses:
1. Looking back
2. Taking stock
3. Future needs
To summarize: The `looking back' unit has the purpose of isolating what we
learned. The `taking stock' unit is to produce a portfolio of projects that
highlight different aspects of the language. The `future needs' unit should
try to clarify what needs to be done next. Papers may include compilations
of issues, provocative questions or hypotheses which can be used to
stimulate and guide discussion in particular areas.
The papers will be reviewed, and up to 30 of them will be selected for
inclusion in the Workshop. We will try to have these papers bound and
mailed to participants before OOPSLA to make the Workshop as efficient as
possible.
Please submit five copies of your papers by August 1 1990 to:
Andreas Paepcke
Hewlett-Packard Laboratory
1501 Page Mill Rd.
Palo Alto, Ca. 94304-1126
paepcke@hplabs.hp.com
Tel: 415-857-7398
Fax: 415-857-8526
We also welcome suggestions for the Workshop format, suggestions for
speakers or other feedback that will help make our Workshop a success.
∂29-Jul-90 2337 Common-Lisp-mailer hash table iterators ordering, etc
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 29 Jul 90 23:37:03 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Mon 30 Jul 90 01:18:52-CDT
Return-Path: <barmar@Think.COM>
Received: from Nugodot.Think.COM by mail.think.com; Mon, 30 Jul 90 02:18:32 -0400
Received: by nugodot.think.com (4.0/Think-1.0C)
id AA02764; Mon, 30 Jul 90 02:18:29 EDT
Date: Mon, 30 Jul 90 02:18:29 EDT
From: barmar@Think.COM
Message-Id: <9007300618.AA02764@nugodot.think.com>
To: jwz@lucid.com
Cc: donc@vaxa.isi.edu, jonl@lucid.com, common-lisp@mcc.com
In-Reply-To: <9007291821.AA05125@challenger>
Subject: hash table iterators ordering, etc
Date: Sun, 29 Jul 90 11:21:27 PDT
From: Jamie Zawinski <jwz@lucid.com>
Rehashing isn't a result of GC, it's a result of adding or deleting things
from the table.
EQL hash tables commonly hash on addresses, so a copying GC would require
these hash tables to be rehashed. MAPHASH and WITH-HASH-TABLE-ITERATOR on
such systems presumably disable GC during their dynamic extent if the hash
table has a GC dependency.
∂30-Jul-90 0629 Common-Lisp-mailer Re: hash table iterators ordering, etc
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 30 Jul 90 06:29:35 PDT
Received: from CHILES.SLISP.CS.CMU.EDU by MCC.COM with TCP/SMTP; Mon 30 Jul 90 08:24:32-CDT
Received: from chiles.slisp.cs.cmu.edu by CHILES.SLISP.CS.CMU.EDU id aa26795;
30 Jul 90 9:23:25 EDT
To: barmar@Think.COM
cc: jwz@lucid.com, donc@vaxa.isi.edu, jonl@lucid.com, common-lisp@mcc.com
Subject: Re: hash table iterators ordering, etc
In-reply-to: Your message of Mon, 30 Jul 90 02:18:29 -0400.
<9007300618.AA02764@nugodot.think.com>
Date: Mon, 30 Jul 90 09:23:04 EDT
Message-ID: <26791.649344184@CHILES.SLISP.CS.CMU.EDU>
From: Bill.Chiles@CHILES.SLISP.CS.CMU.EDU
Date: Sun, 29 Jul 90 11:21:27 PDT
From: Jamie Zawinski <jwz@lucid.com>
Rehashing isn't a result of GC, it's a result of adding or deleting things
from the table.
EQL hash tables commonly hash on addresses, so a copying GC would require
these hash tables to be rehashed. MAPHASH and WITH-HASH-TABLE-ITERATOR on
such systems presumably disable GC during their dynamic extent if the hash
table has a GC dependency.
Barmar, I think what Zawinski is trying to say is that you want to (or have
to) avoid rehashing at GC-time. If you have a stop-and-copy GC without
generational support, you want to avoid finding all the EQ and EQL
hashtables in a 4-6M world (retained memory), so you can recompute every
element's new location in addition to all the paging and other GC thrashing
you just endured. You probably have a access-time rehashing scheme where
you rehash elements in hashtables with moved objects. GC marks the tables,
and that's all the time it wastes. Of course, some hashtables are marked
as having moved, but at access-time the particular method knows whether the
table really needs to be rehashed based on the hashing function. Also, it
is likely you will access only a few of all the world's hashtables between
GC flips which further argues for lazily executing the rehashing.
Either way, hashtable iterating forms need to consider their correctness in
light of moving keys, but this may not be a concern since you aren't
allowed to add or delete elements within these forms (that is, you can't
operate on the hashtable as a hashtable while iterating over it. Loops
that iterate over the low level arrays that implement the hashtables may
maintain their integrity across GC's without rehashing. Note, there is an
exception with REMHASH and (SETF GETHASH), but the manual defines these so
implementations may finesse the results.
Bill
∂30-Jul-90 0910 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 30 Jul 90 09:10:02 PDT
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Mon 30 Jul 90 11:02:21-CDT
Received: from tyrannosaurus.noname (TYRANNOSAURUS.SCRC.Symbolics.COM) by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 539932; 30 Jul 90 12:01:01 EDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by tyrannosaurus.noname (4.1/SMI-4.1)
id AA00491; Mon, 30 Jul 90 12:01:01 EDT
Date: Mon, 30 Jul 90 12:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DOTIMES
To: Common-Lisp@mcc.com
In-Reply-To: <19900727012621.7.RWK@KILIMANJARO.ILA.Dialnet.Symbolics.COM>
Message-Id: <19900730160542.8.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Kerns' message of Thu, 26 Jul 90 21:26 EDT is the most intelligent and
constructive message in this conversation. I earnestly hope that it
does not get lost in the noise.
∂30-Jul-90 0931 Common-Lisp-mailer hash table iterators
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 30 Jul 90 09:31:40 PDT
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Mon 30 Jul 90 11:11:34-CDT
Received: from tyrannosaurus.noname (TYRANNOSAURUS.SCRC.Symbolics.COM) by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 539934; 30 Jul 90 12:10:25 EDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by tyrannosaurus.noname (4.1/SMI-4.1)
id AA00494; Mon, 30 Jul 90 12:10:25 EDT
Date: Mon, 30 Jul 90 12:15 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: hash table iterators
To: common-lisp@mcc.com
In-Reply-To: <9007280047.AA02968@hpai23>
Message-Id: <19900730161506.9.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
There is an enormous amount of confusion about the details of garbage
collection and hash tables in some of the messages in this conversation.
Upon reflection, I am not going to try to clear up the confusion, which
would take too much time and generate too much mail traffic.
I'll just point out that dynamic extent was chosen for the hash table
and package iterators because the contemplated applications only
required dynamic extent and an indefinite extent implementation, while
possible, is much more complex to do with acceptable efficiency.
Forcing implementations to provide the more elegant indefinite extent,
when no one really wanted it and when it would probably produce a
significant performance degradation, seemed like a poor tradeoff.
Remember, Common Lisp has been asked to be an industrially useful Lisp,
not an elegant and beautiful work of art.
∂30-Jul-90 0958 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 30 Jul 90 09:58:11 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Mon 30 Jul 90 11:41:36-CDT
Return-Path: <gls@Think.COM>
Received: from Verdi.Think.COM by mail.think.com; Mon, 30 Jul 90 12:41:08 -0400
Received: from mozart.think.com by verdi.think.com; Mon, 30 Jul 90 12:41:00 EDT
From: gls@Think.COM (Guy Steele)
Received: by mozart.think.com; Mon, 30 Jul 90 12:40:58 EDT
Date: Mon, 30 Jul 90 12:40:58 EDT
Message-Id: <9007301640.AA04421@mozart.think.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Common-Lisp@mcc.com
In-Reply-To: David A. Moon's message of Mon, 30 Jul 90 12:05 EDT <19900730160542.8.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Subject: DOTIMES
Date: Mon, 30 Jul 90 12:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Kerns' message of Thu, 26 Jul 90 21:26 EDT is the most intelligent and
constructive message in this conversation. I earnestly hope that it
does not get lost in the noise.
I have gone back and re-read this message. and concur with Moon
sufficiently strongly that I am willing to risk forty bounce
messages merely to say, "Hear, hear!" I urge everyone else to
re-read that message as well.
--Guy
∂30-Jul-90 1102 Common-Lisp-mailer hash table generators
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 30 Jul 90 11:02:09 PDT
Received: from venera.isi.edu by MCC.COM with TCP/SMTP; Mon 30 Jul 90 12:54:25-CDT
Received: from hpai23.isi.edu by venera.isi.edu (5.61/5.61+local)
id <AA02607>; Mon, 30 Jul 90 10:51:19 -0700
Posted-Date: Mon, 30 Jul 90 13:53:51 EDT
Message-Id: <9007301753.AA12734@hpai23>
Received: by hpai23 (14.5/4.0.3-3)
id AA12734; Mon, 30 Jul 90 13:53:59 edt
To: common-lisp@mcc.com
From: goldman@venera.isi.edu
Subject: hash table generators
Date: Mon, 30 Jul 90 13:53:51 EDT
Sender: goldman@venera.isi.edu
I presume that what people mean by the hash table being "locked"
until the generator is released or exhausted is that it is in a state
where "it is an error" to modify it (except for removing the
"current" entry).
Personally, I don't see the danger of misuse of hashtable generators
to itself be a good reason for omitting them. It is really no
different than things programmers program up themselves with lexical
closures over data structures whose internals are NOT abstracted
away by common lisp -- e.g., using the tail of a list as a
generator state, or an index into a vector.
As far as I can see, the only "collection" datatypes CL provides
that do abstract away their internal representation, and thus make it
impossible to write "generators", are hashtables and packages.
I think providing a generator interface for these would be wise.
HOWEVER, although a generator interface is more general than the
iterators now provided, they are not a substitute. In particular,
the iteration syntax makes it possible to open-code an iteration;
the generator interface requires the consing of a closure and
its application to obtain an entry.
∂30-Jul-90 1403 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 30 Jul 90 14:03:43 PDT
Received: from NSFnet-Relay.AC.UK by MCC.COM with TCP/SMTP; Mon 30 Jul 90 15:57:16-CDT
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa14366; 30 Jul 90 21:44 BST
Date: Mon, 30 Jul 90 21:55:28 BST
Message-Id: <16398.9007302055@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: DOTIMES
To: "Robert W. Kerns" <RWK@fuji.ila.dialnet.symbolics.com>,
"Richard P. Gabriel" <@riverside.scrc.symbolics.com:rpg@lucid.com>,
kab <@riverside.scrc.symbolics.com:kab@charon.mit.edu>
In-Reply-To: Robert W. Kerns's message of Thu, 26 Jul 90 21:26 EDT
Cc: jeff <@riverside.scrc.symbolics.com:jeff@aiai.edinburgh.ac.uk>,
jonl <@riverside.scrc.symbolics.com:jonl@lucid.com>,
snicoud <@riverside.scrc.symbolics.com:snicoud@atc.boeing.com>,
common-lisp <common-lisp@mcc.com>
I agree with the recent praise for RWK's message. Moreover I agree
that:
> Variable semantics is a very fundamental aspect of the
> language, and we have failed to specify an important part
> of it. Traditionally, we have dismissed "style warnings"
> as being an "environment" issue. However, in this case, I
> do not think it should be so dismissed.
And with:
> I strongly feel that a well-written portable Common Lisp
> program should compile with no warnings in any well-done
> Common Lisp implementation. Otherwise, how is the user
> of a portable program supposed to know if the warnings warn
> of actual problems, or are just noise.
>
> I strongly feel that X3J13 should firmly nail down under
> what circumstances "unused variable" and "unused local function"
> warnings may be issued. It is our failure to do so which is
> at the heart of the current issue, and as a porter of code, it
> has been a recurrent problem.
However, I don't want us to have to give a long explanation of
IGNORE, detailing lots of special cases. Instead, the definition
of IGNORE and of such constructs as DOTIMES should be enough
without either having to mention the other explicitly.
In addition, however, we might want to explicitly state some of the
particular consequences of those definitions. That is, don't mind a
discussion of special cases so long as they are consequences of the
basic definitions rather than part of them.
> I think the semantics of the IGNORE declaration should be firmed
> up, and a policy stated about when it is OK to warn about an
> IGNORE'd variable being used. (Does the SETQ implicit in DOTIMES
> (assignment semantics) count as a use, if the result is never
> looked at?)
We should definitely say whether assignment counts as use.
> There are also two capabilities which are missing, which have
> been refered to as an IGNORABLE declaration and a
> COMPILER:INVISIBLE-REFERENCES form, in BARMAR's message.
I am not in favor of compilcating the language further by adding
such capabilities.
-- Jeff
∂31-Jul-90 0235 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 31 Jul 90 02:35:16 PDT
Received: from RIVERSIDE.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Tue 31 Jul 90 04:26:42-CDT
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 479966; 30 Jul 90 22:23:31 EDT
Received: from BUGS-BUNNY.ILA.Dialnet.Symbolics.COM by F.ILA.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 43093; Mon 30-Jul-90 22:29:02 EDT
Date: Mon, 30 Jul 90 22:22 EDT
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Subject: DOTIMES
To: Robert A. Cassels <Cassels@Cassels.SCRC.Symbolics.COM>
cc: RWK@FUJI.ILA.Dialnet.Symbolics.COM, rpg%lucid.com@RIVERSIDE.SCRC.Symbolics.COM,
kab%charon.mit.edu@RIVERSIDE.SCRC.Symbolics.COM, jeff%aiai.edinburgh.ac.uk@RIVERSIDE.SCRC.Symbolics.COM,
jonl%lucid.com@RIVERSIDE.SCRC.Symbolics.COM, snicoud%atc.boeing.com@RIVERSIDE.SCRC.Symbolics.COM,
common-lisp%mcc.com@RIVERSIDE.SCRC.Symbolics.COM
In-Reply-To: <19900727174053.3.CASSELS@GROUSE.SCRC.Symbolics.COM>
Message-ID: <19900731022231.1.RWK@BUGS-BUNNY.ILA.Dialnet.Symbolics.COM>
Date: Fri, 27 Jul 90 13:40 EDT
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Date: Thu, 26 Jul 90 21:26 EDT
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
COMPILER:INVISIBLE-REFERENCES
(WITHOUT-REFERENCES ?) states that the user is *expected* to reference
a particular variable, and that style warnings are appropriate if he
does not.
This is not correct. (COMPILER:INVISIBLE-REFERENCES <variables> . <body>)
tells the compiler that within <body>, references to <variables> are not
to be counted as "uses." So a (DECLARE (IGNORE ..)) variable will not
get a warning if it is referred to within <body>, and a variable which
is not referred to outside <body> will get an unused variable warning.
This is explained in the Genera documentation.
[Believe it or not, but I have *no access* to Genera 8.0
documentation!]
Actually, my statement is correct, as is your description. (That's
because I'm lucky; I did indeed misunderstand the specifics of
COMPILER:INVISIBLE-REFERENCES due to a superficial examination of
it).
I'm describing it from the standpoint of the programmer's intent,
or *WHY* you use it; that is, the effect you wish to create. You're
describing it from the standpoint of how it interacts with the
compiler, or *HOW* to use it.
I think its specifics aren't as easy to use as they could be. I
would rather see a macro you can wrap around the *USER'S* code to
warn if no uses occur *INSIDE*. The way
COMPILER:INVISIBLE-REFERENCES works, the macro's programmer must
wrap it around each non-caller fragment which references the
variable. This may be very difficult or impossible to do when
the variable is passed to other macros requiring variable names!
For example:
(defmacro with-temp-window (window-var &body body)
`(unwind-protect
(progn
(setq ,window-var (make-temp-window :previous ,window-var))
,@body)
(restore-prior-window ,window-var)))
(defmacro with-frobbed-window ((var &rest options
&key &allow-other-keys)
&body body)
`(let ((,var (make-window ,@options)))
(with-temp-window ,var
(WITH-REFERENCES (,var) ;; References *needed* within
;; unless (DECLARE (IGNORE ...))
,@body))))
I don't see how you could do this with
COMPILER:INVISIBLE-REFERENCES (without modifying
WITH-TEMP-WINDOW, which might not be your macro).
However, I do think that both forms are actually needed:
(defmacro with-window-frobber (window-var &body body)
`(with-frobbed-window (,window-var :twisted t)
(labels ((frobit ()
;; These references don't count for the
;; WITH-REFERENCES inside
;; WITH-FROBBED-WINDOW
(COMPILER:INVISIBLE-REFERENCES (,window-var)
(setq ,window-var
(frob-window-internal ,window-var)))))
(declare (IGNORABLE #'FROBIT)) ;; References *optional*
,@body)))
I haven't yet thought out how WITH-REFERENCES would
interact with a (DECLARE (IGNORE ...)) outside it;
I'll save that thinking for another night.
∂31-Jul-90 0505 Common-Lisp-mailer Hash tables
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 31 Jul 90 05:05:40 PDT
Received: from NADC.NADC.NAVY.MIL by MCC.COM with TCP/SMTP; Tue 31 Jul 90 06:59:51-CDT
Received: by NADC.NADC.NAVY.MIL (5.59/1.0 )
id AA21294; Tue, 31 Jul 90 08:00:00 EDT
Date: Tue, 31 Jul 90 08:00:00 EDT
From: silbert@NADC.NADC.NAVY.MIL (M. Silbert)
Message-Id: <9007311200.AA21294@NADC.NADC.NAVY.MIL>
To: common-lisp@mcc.com
Subject: Hash tables
Cc: silbert@NADC.NADC.NAVY.MIL
I feel I've always been missing the boat on the hash function's
test restrictions. Namely, why is the test function on hash tables
restricted to be EQ, EQL or EQUAL? Why can't it be, for instance,
"=" in the case when the keys are numeric?
For that matter, why can't I use some arbitrary (e.g., user-defined)
test function? It seems to me that hash tables are suppose to be
conceptually equivalent to p-lists but p-lists allow any test function
while hash tables do not.
Another issue that puzzles me about the MAKE-HASH-TABLE function is
that it doesn't allow the user to specify an alternative hashing
function with the default function being SXHASH. An example of where
it would be useful in specifying an alternative hashing function occurs
in producing a portable way to use user-defined structures as keys.
Suppose we consider two structures equal if they are the same structure
(i.e., they are EQ to each other). It becomes messy and computationally
expensive to hash on the entire structure contents. A portable way
around this problem is to add an extra slot to the structure when its
defined. We then create a global counter that is incremented
each time a structure is instantiated. The value of the counter is then
placed into the added slot of the structure. To use these structure
objects as keys, we create a hash table that uses the slot accessor
function as the hashing function instead of SXHASH: simple, quick
and efficient.
MES
∂31-Jul-90 0613 Common-Lisp-mailer Hash tables
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 31 Jul 90 06:13:26 PDT
Received: from YUKON.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Tue 31 Jul 90 08:06:35-CDT
Received: from LILIKOI.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via INTERNET with SMTP id 603125; 31 Jul 90 09:07:35 EDT
Date: Tue, 31 Jul 90 09:09 EDT
From: Mark Nahabedian <naha@YUKON.SCRC.Symbolics.COM>
Subject: Hash tables
To: silbert@NADC.NADC.NAVY.MIL, common-lisp@mcc.com
In-Reply-To: <9007311200.AA21294@NADC.NADC.NAVY.MIL>
Message-ID: <19900731130905.3.NAHA@LILIKOI.SCRC.Symbolics.COM>
Date: Tue, 31 Jul 90 08:00:00 EDT
From: silbert@NADC.NADC.NAVY.MIL (M. Silbert)
I feel I've always been missing the boat on the hash function's
test restrictions. Namely, why is the test function on hash tables
restricted to be EQ, EQL or EQUAL? Why can't it be, for instance,
"=" in the case when the keys are numeric?
For that matter, why can't I use some arbitrary (e.g., user-defined)
test function? It seems to me that hash tables are suppose to be
conceptually equivalent to p-lists but p-lists allow any test function
while hash tables do not.
I imagine it is because these are the only predicates that it knows good
hashing algorithms for. It can't divine a hashing function from a
predicate, some programmer has to teach it one.
Another issue that puzzles me about the MAKE-HASH-TABLE function is
that it doesn't allow the user to specify an alternative hashing
function with the default function being SXHASH.
The Symbolics CommonLisp version of MAKE-HASH-TABLE provides a keyword
argument allowing the user to provide a hashing function. The default
is one that is selected based on the test function. This is an
extension to the behavior described in CLTL2. I don't know what the
behavior proposed by the X3J13 draft standard is. I imagine that for
some reason the committe chose not to allow the user to specify a
hashing function. I suppose that one could write a function which maps
the things which one would like to use as keys to numbers and then use an
EQL hash table, remembering to translate ones abstract keys into numeric
keys suitable for the table.
An example of where
it would be useful in specifying an alternative hashing function occurs
in producing a portable way to use user-defined structures as keys.
Suppose we consider two structures equal if they are the same structure
(i.e., they are EQ to each other). It becomes messy and computationally
expensive to hash on the entire structure contents. A portable way
around this problem is to add an extra slot to the structure when its
defined. We then create a global counter that is incremented
each time a structure is instantiated. The value of the counter is then
placed into the added slot of the structure. To use these structure
objects as keys, we create a hash table that uses the slot accessor
function as the hashing function instead of SXHASH: simple, quick
and efficient.
MES
∂31-Jul-90 0755 Common-Lisp-mailer Hash tables
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 31 Jul 90 07:55:52 PDT
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Tue 31 Jul 90 09:49:29-CDT
Received: from tyrannosaurus.noname (TYRANNOSAURUS.SCRC.Symbolics.COM) by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 540320; 31 Jul 90 10:48:22 EDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by tyrannosaurus.noname (4.1/SMI-4.1)
id AA00788; Tue, 31 Jul 90 10:47:54 EDT
Date: Tue, 31 Jul 90 10:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Hash tables
To: M. Silbert <silbert@NADC.NADC.NAVY.MIL>
Cc: common-lisp@mcc.com
In-Reply-To: <9007311200.AA21294@NADC.NADC.NAVY.MIL>
Message-Id: <19900731145227.9.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Tue, 31 Jul 90 08:00:00 EDT
From: silbert@NADC.NADC.NAVY.MIL (M. Silbert)
I feel I've always been missing the boat on the hash function's
test restrictions. Namely, why is the test function on hash tables
restricted to be EQ, EQL or EQUAL? Why can't it be, for instance,
"=" in the case when the keys are numeric?
Because the = function in CLtL Common Lisp is not transitive, and only
transitive equality functions can work as consistent hash table tests. The
language changes necessary to fix this are discussed in X3J13 cleanup issues
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE and HASH-TABLE-TESTS:ADD-EQUALP,
both of which have been accepted by X3J13. (I don't know why X3J13 accepted
EQUALP as an additional test, but not =; = is simply a type-restricted version
of EQUALP). X3J13 cleanup issues are available by anonymous FTP from some
directory or other on ARISIA.XEROX.COM. On this particular subject you can
also refer to pages 109 and 290 of Common Lisp the Language Second Edition.
For that matter, why can't I use some arbitrary (e.g., user-defined)
test function? It seems to me that hash tables are suppose to be
conceptually equivalent to p-lists but p-lists allow any test function
while hash tables do not.
A hash table requires a coordinated pair of a test function and a hash
function. The hash function must map keys to fixnums in a way that is
consistent with the test functions (equivalent keys map to equal fixnums),
well-distributed (non-equivalent keys have a high probability of mapping to
unequal fixnums), and properly coordinated with garbage collection. So far
there has not been a satisfactory proposal for an implementation-independent
protocol to be followed by the hash function. I don't think it's even agreed
that it's right to standardize on fixnums as the range of the hash function.
I myself think it would be a good idea to add such a capability to the
language (and Symbolics Genera has long had it as an extension, but of course
it's easier if you don't have to be implementation-independent). However
X3J13 can't add it to the language if there isn't a satisfactory proposal. At
this stage even a satisfactory proposal might not be accepted into the
developing standard, since it has been over a year since we supposedly froze
the language and stopped adding features.
By the way, Symbolics Genera has not yet adopted the language changes
described in CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE that are necessary
to allow EQUALP and = as hash table tests, because the changes are
incompatible with CLtL.
Another issue that puzzles me about the MAKE-HASH-TABLE function is
that it doesn't allow the user to specify an alternative hashing
function with the default function being SXHASH.
SXHASH is not consistent with certain test functions, EQUALP for example.
It is really not possible for there to be a default hashing function that
works for any test, other than the trivial hashing function that always
returns the same value, which obviously is not well-distributed.
∂31-Jul-90 0813 Common-Lisp-mailer Hash tables
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 31 Jul 90 08:13:13 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Tue 31 Jul 90 09:52:20-CDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 827597; 31 Jul 90 10:51:28 EDT
Date: Tue, 31 Jul 90 10:55 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Hash tables
To: M. Silbert <silbert@NADC.NADC.NAVY.MIL>
cc: common-lisp@mcc.com
In-Reply-To: <9007311200.AA21294@NADC.NADC.NAVY.MIL>
Supersedes: <19900731145227.9.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Comments: Retransmitted through a less broken mailer. If both copies
get through, I apologize in advance for the junk-mail.
Message-ID: <19900731145530.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Date: Tue, 31 Jul 90 08:00:00 EDT
From: silbert@NADC.NADC.NAVY.MIL (M. Silbert)
I feel I've always been missing the boat on the hash function's
test restrictions. Namely, why is the test function on hash tables
restricted to be EQ, EQL or EQUAL? Why can't it be, for instance,
"=" in the case when the keys are numeric?
Because the = function in CLtL Common Lisp is not transitive, and only
transitive equality functions can work as consistent hash table tests. The
language changes necessary to fix this are discussed in X3J13 cleanup issues
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE and HASH-TABLE-TESTS:ADD-EQUALP,
both of which have been accepted by X3J13. (I don't know why X3J13 accepted
EQUALP as an additional test, but not =; = is simply a type-restricted version
of EQUALP). X3J13 cleanup issues are available by anonymous FTP from some
directory or other on ARISIA.XEROX.COM. On this particular subject you can
also refer to pages 109 and 290 of Common Lisp the Language Second Edition.
For that matter, why can't I use some arbitrary (e.g., user-defined)
test function? It seems to me that hash tables are suppose to be
conceptually equivalent to p-lists but p-lists allow any test function
while hash tables do not.
A hash table requires a coordinated pair of a test function and a hash
function. The hash function must map keys to fixnums in a way that is
consistent with the test functions (equivalent keys map to equal fixnums),
well-distributed (non-equivalent keys have a high probability of mapping to
unequal fixnums), and properly coordinated with garbage collection. So far
there has not been a satisfactory proposal for an implementation-independent
protocol to be followed by the hash function. I don't think it's even agreed
that it's right to standardize on fixnums as the range of the hash function.
I myself think it would be a good idea to add such a capability to the
language (and Symbolics Genera has long had it as an extension, but of course
it's easier if you don't have to be implementation-independent). However
X3J13 can't add it to the language if there isn't a satisfactory proposal. At
this stage even a satisfactory proposal might not be accepted into the
developing standard, since it has been over a year since we supposedly froze
the language and stopped adding features.
By the way, Symbolics Genera has not yet adopted the language changes
described in CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE that are necessary
to allow EQUALP and = as hash table tests, because the changes are
incompatible with CLtL.
Another issue that puzzles me about the MAKE-HASH-TABLE function is
that it doesn't allow the user to specify an alternative hashing
function with the default function being SXHASH.
SXHASH is not consistent with certain test functions, EQUALP for example.
It is really not possible for there to be a default hashing function that
works for any test, other than the trivial hashing function that always
returns the same value, which obviously is not well-distributed.
∂31-Jul-90 1029 Common-Lisp-mailer Hash tables
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 31 Jul 90 10:29:24 PDT
Received: from mail.think.com by MCC.COM with TCP/SMTP; Tue 31 Jul 90 12:21:51-CDT
Return-Path: <barmar@Think.COM>
Received: from Sfs-Akv.Think.COM by mail.think.com; Tue, 31 Jul 90 13:21:47 -0400
Received: from OCCAM.THINK.COM by sfs-akv.think.com (4.0/Think-1.0C)
id AA14364; Tue, 31 Jul 90 13:21:44 EDT
Date: Tue, 31 Jul 90 13:21 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Hash tables
To: M. Silbert <silbert@NADC.NADC.NAVY.MIL>
Cc: common-lisp@mcc.com
In-Reply-To: <9007311200.AA21294@NADC.NADC.NAVY.MIL>
Message-Id: <19900731172134.6.BARMAR@OCCAM.THINK.COM>
Date: Tue, 31 Jul 90 08:00:00 EDT
From: silbert@NADC.NADC.NAVY.MIL (M. Silbert)
I feel I've always been missing the boat on the hash function's
test restrictions. Namely, why is the test function on hash tables
restricted to be EQ, EQL or EQUAL? Why can't it be, for instance,
"=" in the case when the keys are numeric?
The original CLtL definition of "=" didn't define an equivalence class
appropriate for hashing. Because of the rule that in (= <float>
<rational>), the rational is converted to a float, = was not transitive:
you could have situations where (= <float> <rational1>) and (= <float>
<rational2>) but not (= <rational1> <rational2>). Consider the
following sequence:
(setq a (/ 10.0 single-float-epsilon)
j (floor a)
ht (make-hash-table :test #'=))
(setf (gethash j ht) 'one
(gethash (1+ j) ht) 'two)
(gethash j ht) => ONE
(gethash (1+ j) ht) => TWO
(= j a) => T
(= (1+ j) a) => T
(= j (1+ j)) => NIL
(gethash a ht) => ???
For that matter, why can't I use some arbitrary (e.g., user-defined)
test function? It seems to me that hash tables are suppose to be
conceptually equivalent to p-lists but p-lists allow any test function
while hash tables do not.
I think you're thinking of alists, not plists (GETF doesn't have a TEST
argument, but ASSOC does). Alists are ordered, so the result of ASSOC
is well-defined even when the test function doesn't define an
equivalence class (it returns the first entry that satisfies the test).
Hash tables have no inherent ordering, so well-defined behavior depends
on the test function being transitive.
As naha pointed out, when you specify a test function, you must also
specify a corresponding hash function. Actually, a larger can of worms
is opened up. For instance, you also need to be able to specify
conditions under which the hash table must be rehashed if the hash
function is sensitive to some state outside the objects themselves.
I think user-extensible hashing was considered by the Common Lisp
designers, but it was left out because there wasn't enough experience
with it.
Another issue that puzzles me about the MAKE-HASH-TABLE function is
that it doesn't allow the user to specify an alternative hashing
function with the default function being SXHASH.
You're assuming that SXHASH is an appropriate hashing function for EQUAL
hash tables in the first place. In Genera, SXHASH returns the same
value for all structures (it doesn't recurse into them); for data types
where EQUAL is defined to be equivalent to EQL the hash table
implementation uses the internal hashing function that is used for EQL
hash tables (and marks the hash table as needing to be rehashed
following a GC).
An example of where
it would be useful in specifying an alternative hashing function occurs
in producing a portable way to use user-defined structures as keys.
Suppose we consider two structures equal if they are the same structure
(i.e., they are EQ to each other). It becomes messy and computationally
expensive to hash on the entire structure contents.
Since non-EQ structures can never be EQUAL or EQUALP, there's no reason
the hash table implementation should hash on the structure contents.
barmar
∂02-Aug-90 1150 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Aug 90 11:50:38 PDT
Received: from RIVERSIDE.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Thu 2 Aug 90 13:29:21-CDT
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 481086; 2 Aug 90 14:25:45 EDT
Received: from KILIMANJARO.ILA.Dialnet.Symbolics.COM by F.ILA.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 43294; Thu 2-Aug-90 14:31:35 EDT
Date: Thu, 2 Aug 90 14:35 EDT
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Subject: Re: DOTIMES
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@Riverside.SCRC.Symbolics.COM>,
Richard P. Gabriel <rpg%lucid.com@riverside.scrc.symbolics.com>, kab <kab%charon.mit.edu@riverside.scrc.symbolics.com>
cc: jonl <jonl%lucid.com@riverside.scrc.symbolics.com>, snicoud <snicoud%atc.boeing.com@riverside.scrc.symbolics.com>,
common-lisp <common-lisp%mcc.com@riverside.scrc.symbolics.com>
In-Reply-To: <16398.9007302055@subnode.aiai.ed.ac.uk>
Message-ID: <19900802183548.2.RWK@KILIMANJARO.ILA.Dialnet.Symbolics.COM>
Is it about time to move the productive portion of this
discussion to X3J13 to hammer out a proposal? (I don't
mean to belittle the other portions of the discussion;
just that they're not likely to result in a concrete
proposal soon). Or is there a core group of people
interested in hashing out a proposal first?
I would add that I would rather this had all been dealt
with much earlier, but my experiences over the last several
months with porting software (especially when Symbolics
changed behaviours from implementation to implementation
and release to release) have led me to realize that this
is a lot more important than I had realized.
Besides, I had always assumed that someone else would turn
the IGNORABLE idea into a proposal. Well, we all know about
Somebody, Anybody, and Nobody, right?
Date: Mon, 30 Jul 90 21:55:28 BST
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
However, I don't want us to have to give a long explanation of
IGNORE, detailing lots of special cases. Instead, the definition
of IGNORE and of such constructs as DOTIMES should be enough
without either having to mention the other explicitly.
I don't think it's very hard at all to describe. All we have
to do is:
1) Specify whether or not SETQ counts as a reference. (I haven't
decided my vote on this point).
1a) A slot value in WITH-SLOTS is always already referenced, by the
instance.
2) Specify that a variable not referenced may be warned about.
(No implementation is ever REQUIRED to warn of unused references).
3a) Specify that a variable declared IGNORE is not warned about
if not used.
3b) Specify a variable declared IGNORE is MAY be warned about
if the variable *IS* used. (IGNORE asserts that a variable
is not used in the relevant lexical contour).
4a) Specify that a variable declared IGNORABLE is not warned
about if not used.
4b) Specify that a variable declared IGNORABLE is MAY NOT
cause a warning if the variable *IS* used. (IGNORABLE
asserts that a variable's usage in the contour is optional.)
5) Specify whether DOTIMES and DOLIST reference their vars.
(If they don't, I think one of the additional features I
discuss below are required.)
6) Add the #'local-function-name syntax to IGNORE and IGNORABLE
for supressing warnings about unused local functions.
In addition, however, we might want to explicitly state some of the
particular consequences of those definitions. That is, don't mind a
discussion of special cases so long as they are consequences of the
basic definitions rather than part of them.
Agreed. However, I'm unaware of any special cases, given the
above definitions. Of course, examples of non-special cases
are always a valuable aid to understanding.
We should definitely say whether assignment counts as use.
Indeed, that issue resulted in a gross incompatibility between
Genera 7 on non-Ivory and Ivory systems from the same vendor!
> There are also two capabilities which are missing, which have
> been refered to as an IGNORABLE declaration and a
> COMPILER:INVISIBLE-REFERENCES form, in BARMAR's message.
I am not in favor of compilcating the language further by adding
such capabilities.
The benefits for the writers of macros are very large, and
the definitions are pretty simple. Let me at this point
suggest new names: IGNORING-REFERENCES-INSIDE and
IGNORING-REFERENCES-OUTSIDE. At least one of these is
required in order to be able to define DOTIMES with the
definition I prefer.
Regardless of which way we actually define DOTIMES, I consider
it a serious flaw that I cannot portably define macros which
have this behaviuor.
IGNORING-REFERENCES-INSIDE (&rest variables) &body body
Any references to VARIABLES inside BODY are not counted
as references for the sake of warnings for the lexical scope
outside of this form. It is not permitted to warn of
unreferenced occurances of the VARIABLES inside the body
(unless an IGNORING-REFERENCES-OUTSIDE is nested within).
(I could be convinced to reverse the above statement to
"is permitted to warn of unreferenced variables inside the
body", for the sake of additional error checking.
However, from an aesthetic point of view, I think this
creates a more minimal and orthogonal semantics for this
form. You can always nest an IGNORING-REFERENCES-OUTSIDE
form.)
(Implementations are free to simply supress warnings
for the variables without regard to scope, since these
warnings are always optional. The required burden on
compiler writers is minimal; basically requiring only
that the mechanism for IGNORE be invokable in another
position).
IGNORING-REFERENCES-OUTSIDE (&rest variables) &body body
Regardless of any references outside the lexical scope
of this form, it is permitted to warn about unused occurrances
of the variables inside BODY, in a manner as if the variables
were freshly bound. (They are *NOT* rebound). Declarations
for IGNORE and IGNORABLE are allowed as the first form of
BODY.
References inside BODY are not counted as references for the
lexical code outside BODY. This is done to keep things simpler.
The semantics wrt warnings is then that it is treated for warnings
as if it were a new variable. This could be done, for example,
by setting and restoring the REFERENCED slot in the compiler's
variable structure with an UNWIND-PROTECT.
(Since warnings are optional, implementations are free to strip
out the declarations, and thence treat this as if it were
(IGNORING-REFERENCES-INSIDE <variables> . <body-less-declarations>).
Such an implementation will not warn if the variables are not
used inside BODY, but will also not issue any spurious warnings).
One way of looking at these is that IGNORING-REFERENCES-INSIDE
is used for hiding a set of references from the warning
mechanism, so that they don't interfere with detecting
unreferenced user variables. It is used to hide "system" uses
of user variables imbedded in user code contained in
macroexpansions.
IGNORING-REFERENCES-OUTSIDE is for establishing a new scope
for detecting unused variables in user code, despite the
presence of references outside the scope. It is used to wrap
around user-supplied code imbeded in macro expansions
containing "system" uses of user variables.
∂02-Aug-90 1217 Common-Lisp-mailer Hash tables
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Aug 90 12:17:13 PDT
Received: from RIVERSIDE.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Thu 2 Aug 90 14:09:35-CDT
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 481104; 2 Aug 90 15:07:36 EDT
Received: from KILIMANJARO.ILA.Dialnet.Symbolics.COM by F.ILA.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 43299; Thu 2-Aug-90 15:13:30 EDT
Date: Thu, 2 Aug 90 15:17 EDT
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Subject: Hash tables
To: M. Silbert <silbert%nadc.nadc.navy.mil@Riverside.SCRC.Symbolics.COM>,
common-lisp%mcc.com@Riverside.SCRC.Symbolics.COM
In-Reply-To: <9007311200.AA21294@NADC.NADC.NAVY.MIL>
Message-ID: <19900802191744.5.RWK@KILIMANJARO.ILA.Dialnet.Symbolics.COM>
Date: Tue, 31 Jul 90 08:00:00 EDT
From: silbert@nadc.nadc.navy.mil (M. Silbert)
I feel I've always been missing the boat on the hash function's
test restrictions. Namely, why is the test function on hash tables
restricted to be EQ, EQL or EQUAL? Why can't it be, for instance,
"=" in the case when the keys are numeric?
X3J13 has voted to also allowing EQUALP (which includes =).
In addition, there is a proposal in the works for a protocol
to allow people to define additional test/hash combinations.
(Kim Barret has spearheaded it; I don't remember who the other
participants have been).
It is more complicated to do so portably than it seems,
because of the GC issues, which is why it's taken so long.
However, because of the late date, we've decided it will *NOT*
be brought up before X3J13 for inclusion in the version of the
standard currently being drafted.
Dissapointing to us hash-table fans, yes, but we have to draw
the line somewhere if we're going to produce a standard.
For that matter, why can't I use some arbitrary (e.g., user-defined)
test function? It seems to me that hash tables are suppose to be
conceptually equivalent to p-lists but p-lists allow any test function
while hash tables do not.
I think you mean alists, not plists, since the plist
accessors don't take test functions. But anyway...
* Alists do not involve hashing.
* Alists can have multiple entries for a single key.
* Even alists can exhibit weird behaviour when the
test function is non-transitive.
* Alists require the specification of the test for
each access, and the test can be different at different
times. Hash tables require it to be specified at table
creation time, and do not allow it to be changed.
I'd say "conceptually related" is the phrase, not
"conceptually equivalent".
Another issue that puzzles me about the MAKE-HASH-TABLE function is
that it doesn't allow the user to specify an alternative hashing
function with the default function being SXHASH. An example of where
it would be useful in specifying an alternative hashing function occurs
in producing a portable way to use user-defined structures as keys.
Suppose we consider two structures equal if they are the same structure
(i.e., they are EQ to each other). It becomes messy and computationally
expensive to hash on the entire structure contents. A portable way
around this problem is to add an extra slot to the structure when its
defined. We then create a global counter that is incremented
each time a structure is instantiated. The value of the counter is then
placed into the added slot of the structure. To use these structure
objects as keys, we create a hash table that uses the slot accessor
function as the hashing function instead of SXHASH: simple, quick
and efficient.
SXHASH and hash tables have *nothing* to do with each other,
except for technique. Except possibly for a very few implementations
of EQUAL hash tables, SXHASH cannot be used by hash tables, because
of the GC issues.
Hashing for hash tables is a little more complex than you realize,
although it's managable with a suitable protocol. The proposal is
for the hashing function to return two values, with the second value
being a value relating to the GC status of the object being hashed,
and with these values being computed and combined in an implementation-
dependent manner.
∂02-Aug-90 1251 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Aug 90 12:51:37 PDT
Received: from NSFnet-Relay.AC.UK by MCC.COM with TCP/SMTP; Thu 2 Aug 90 14:45:52-CDT
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa12464; 2 Aug 90 20:30 BST
Date: Thu, 2 Aug 90 20:43:58 BST
Message-Id: <27007.9008021943@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: DOTIMES
To: "Robert W. Kerns" <RWK@fuji.ila.dialnet.symbolics.com>,
Jeff Dalton <@riverside.scrc.symbolics.com:jeff@aiai.edinburgh.ac.uk>,
"Richard P. Gabriel" <@riverside.scrc.symbolics.com:rpg@lucid.com>,
kab <@riverside.scrc.symbolics.com:kab@charon.mit.edu>
In-Reply-To: Robert W. Kerns's message of Thu, 2 Aug 90 14:35 EDT
Cc: jonl <@riverside.scrc.symbolics.com:jonl@lucid.com>,
snicoud <@riverside.scrc.symbolics.com:snicoud@atc.boeing.com>,
common-lisp <common-lisp@mcc.com>
> 5) Specify whether DOTIMES and DOLIST reference their vars.
> (If they don't, I think one of the additional features I
> discuss below are required.)
I wrote:
> In addition, however, we might want to explicitly state some of the
> particular consequences of those definitions. That is, don't mind a
> discussion of special cases so long as they are consequences of the
> basic definitions rather than part of them.
> Agreed. However, I'm unaware of any special cases, given the
> above definitions. Of course, examples of non-special cases
> are always a valuable aid to understanding.
I regard rule 5 as a special case.
We ought (in my view) define DOTIMES so that it implies the
behavior of IGNORE w/o having to explicitly say how they
interact.
∂02-Aug-90 1728 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 2 Aug 90 17:28:35 PDT
Received: from RIVERSIDE.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Thu 2 Aug 90 19:19:42-CDT
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 481353; 2 Aug 90 20:16:16 EDT
Received: from KILIMANJARO.ILA.Dialnet.Symbolics.COM by F.ILA.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 43335; Thu 2-Aug-90 19:00:05 EDT
Date: Thu, 2 Aug 90 19:04 EDT
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Subject: Re: DOTIMES
To: Jeff Dalton <jeff%AIAI.Edinburgh.AC.UK@Riverside.SCRC.Symbolics.COM>,
Richard P. Gabriel <rpg%Lucid.COM@Riverside.SCRC.Symbolics.COM>, kab <kab%Charon.MIT.EDU@Riverside.SCRC.Symbolics.COM>
cc: jonl <jonl%Lucid.COM@Riverside.SCRC.Symbolics.COM>, snicoud <snicoud%atc.Boeing.COM@Riverside.SCRC.Symbolics.COM>,
common-lisp <common-lisp%mcc.com@Riverside.SCRC.Symbolics.COM>
In-Reply-To: <27007.9008021943@subnode.aiai.ed.ac.uk>
Message-ID: <19900802230414.8.RWK@KILIMANJARO.ILA.Dialnet.Symbolics.COM>
Date: Thu, 2 Aug 90 20:43:58 BST
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
> Agreed. However, I'm unaware of any special cases, given the
> above definitions. Of course, examples of non-special cases
> are always a valuable aid to understanding.
I regard rule 5 as a special case.
Well, I don't see anything tricky or special about it, hence
my remark. I do think we should specify this aspect of the
various CL variable binding forms. For example, we should
say that LET's variables are initially unreferenced.
You wrote:
> In addition, however, we might want to explicitly state some of the
> particular consequences of those definitions. That is, don't mind a
> discussion of special cases so long as they are consequences of the
> basic definitions rather than part of them.
Note that there is simply *NO WAY* to regard these as CONSEQUENCES
of ANY set of rules; DOTIMES is simply not tightly enough specified
to make any deductions about the state of its variables. We could
discuss consequences if we had a definition of DOTIMES in the form
of code; for various reasons we will not have that.
We have to specify DOTIMES (and others) more tightly. Even specifying
the binding semantics for DOTIMES does *NOT* specify the referencedness
of the variables; an implementation could insert an (CHECK-TYPE I INTEGER).
It may be obvious to us both that that is unwise, but this is a spec
we're trying to write here, not a manual of implementation technique.
I believe I show below that the additional specification involved
can be done in a single word per binding form.
We ought (in my view) define DOTIMES so that it implies the
behavior of IGNORE w/o having to explicitly say how they
interact.
Huh? Are you saying you'd define DOTIMES as if it included
a (DECLARE (IGNORE I)) in your expansion? That it would therefore
always warn? Or always warn if you use it? Surely I've failed
to understand your point!
There are three basic states the DOTIMES variable (or any other
variable) could be in:
Unreferenced (i.e. use expected)
Referenced (or IGNORABLE; i.e. use optional)
IGNORE'd (I.e. use would be contrary to declaration).
[If you're wondering about symetry, there's a fourth
one, IGNORE'd-and-referenced, which will always warn].
Perhaps we should just define these three states, indicate
which state each declaration puts a variable in, and what
warnings are allowed if you do or do not use such a variable.
Then we can just say which of the three states DOLIST and
DOTIMES (and DO and DO* and LOOP and...) leave their
variables in. (I vote for Unreferenced, but Referenced is
OK. IGNORE'd is clearly wrong).
By the way, there was a trival but fundamental bug in my message:
This point:
2) Specify that a variable not referenced may be warned about.
(No implementation is ever REQUIRED to warn of unused references).
should have been two complimentary points:
2a) Specify that a variable not referenced MAY be warned about.
(No implementation is ever REQUIRED to warn of unused references).
2b) Specify that a variable which is referenced may NOT be warned about,
unless it had an IGNORE declaration.
(Implementations should not issue bogus warnings of unused references,
and should not warn when ordinary variables ARE referenced).
The whole point of this is to eliminate bogus warnings, and point 2b is
needed for that purpose. It seemed "obvious", so I forgot to write it
down.
Here's a table of what state each thing places a variable VAR into.
States in parenthesis are alternatives for consideration.
Form State
(LET ((VAR ..)) ...) Unreferenced
(FOO VAR) Referenced
(SETQ VAR ...) Referenced (No Change)
(DECLARE (IGNORE VAR)) IGNORE'd
(DECLARE (IGNORABLE VAR) Referenced
(IGNORING-REFERENCES-INSIDE (VAR) <here>) Referenced (No Change)
<here> (IGNORING-REFERENCES-INSIDE (VAR) VAR) <here>)
No Change or
Referenced [Implementation option]
(PROGN VAR (IGNORING-REFERENCES-OUTSIDE (VAR) <here>)
Proposed:
Unreferenced
(DOLIST (VAR ...) ...) Unreferenced
(DOTIMES (VAR ...) ...) Unreferenced
(LOOP I = X THEN (FOO X) DO <here>) Unreferenced
(LOOP I = X THEN (FOO I) DO <here>) Referenced
(DO ((I X (FOO X))) (NIL) <here>) Unreferenced
(DO ((I X (FOO I))) (NIL) <here>) Referenced
(DO-ALL-SYMBOLS (VAR PKG) <here>) Unreferenced
(DO-SYMBOLS (VAR PKG) <here>) Unreferenced
(DEFMETHOD YOW ((VAR MY-CLASS)) <here>) Referenced
(DEFMETHOD YOW ((FOO MY-CLASS) VAR) <here>) Unreferenced
(DEFMETHOD YOW ((FOO MY-CLASS) VAR)
(CALL-NEXT-METHOD)
<here>) Unreferenced
This list isn't complete, but I think it demonstrates how easily
these things can be specified, once the right framework is in place.
By the way, unless there's some specification language floating
around somewhere that I've forgotten, the DEFMETHOD case above
is another issue. I actually expected that the first DEFMETHOD
case above would be Unreferenced, not Referenced. However, all
implementations of CLOS that I've used implement the behaviour
I documented above.
I also expected that the CALL-NEXT-METHOD case would be
Unreferenced, not Referenced. That it's Unreferenced is
a consequence of the particular way that CALL-NEXT-METHOD
is implemented, to allow (CALL-NEXT-METHOD) to reference
the initial actual arguments, even if the apparent arguments
have been SETQ'd. Not obvious at all!
There's another issue I hadn't addressed. Should (PROGN VAR NIL)
imply Referenced? Or are compilers allowed to optimize that away,
and warn that VAR is unreferenced? From the standpoint of
understandability, it should be Referenced, but I have seen some
compilers in some circumstances optimize these away and then warn.
I would be in favor of leaving this explicitly unspecified, to
minimize the cost to implementors, and to discourage this paradigm
as a substitute for the more understandable IGNORABLE declaration.
We could specify it as Referenced and not add IGNORABLE, but I think
that would be a poor design from aesthetic grounds as well as
compatibility grounds. The current practice of mentioning variables
in this way to place them into the Referenced state is an unreliable
kludge that some compilers see through.
∂03-Aug-90 0920 Common-Lisp-mailer Re: DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 3 Aug 90 09:20:02 PDT
Received: from NSFnet-Relay.AC.UK by MCC.COM with TCP/SMTP; Fri 3 Aug 90 11:02:58-CDT
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK
via Janet with NIFTP id aa08109; 3 Aug 90 16:38 BST
Date: Fri, 3 Aug 90 16:51:52 BST
Message-Id: <29389.9008031551@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: DOTIMES
To: "Robert W. Kerns" <RWK@fuji.ila.dialnet.symbolics.com>,
Jeff Dalton <@riverside.scrc.symbolics.com:jeff@aiai.edinburgh.ac.uk>,
"Richard P. Gabriel" <@riverside.scrc.symbolics.com:rpg@lucid.com>,
kab <@riverside.scrc.symbolics.com:kab@charon.mit.edu>
In-Reply-To: Robert W. Kerns's message of Thu, 2 Aug 90 19:04 EDT
Cc: jonl <@riverside.scrc.symbolics.com:jonl@lucid.com>,
snicoud <@riverside.scrc.symbolics.com:snicoud@atc.boeing.com>,
common-lisp <common-lisp@mcc.com>
The amazing number of bad addresses on this list is, well, amazing.
> I regard rule 5 as a special case.
>
> Well, I don't see anything tricky or special about it, hence
> my remark. I do think we should specify this aspect of the
> various CL variable binding forms. For example, we should
> say that LET's variables are initially unreferenced.
I think it should be specified (or else IGNORE eliminated), but the
language is more compilcated if we have to do it case by case. One
advantage to specifying DOTIMES in terms of more basic constructs is
that this could give us the meaning of IGNORE in a DOTIMES without our
having to specify it as a separate case.
However, although I happen to think that might be a good way to define
DOTIMES, I'm not wedded to that approach. Some other technique might
well be better, all things considered.
But I still want to make an orthogonality point. We shouldn't have to
specify something by saying what it does in every case where it can
occur. This makes the language more complex, and the suspicion that
Common Lisp constructs are intertwined in this way is one of the
chief criticisms of Common Lisp (at least in the UK).
Indeed, one of the defects of the cleanup process is that it almost
never produces a simplification.
> You wrote:
>
> > In addition, however, we might want to explicitly state some of the
> > particular consequences of those definitions. That is, don't mind a
> > discussion of special cases so long as they are consequences of the
> > basic definitions rather than part of them.
>
> Note that there is simply *NO WAY* to regard these as CONSEQUENCES
> of ANY set of rules; DOTIMES is simply not tightly enough specified
> to make any deductions about the state of its variables.
That's one reason why I think it should be specified more tightly.
> We could discuss consequences if we had a definition of DOTIMES in the
> form of code; for various reasons we will not have that.
I agree on both points.
> I believe I show below that the additional specification involved
> can be done in a single word per binding form.
That would be good.
> We ought (in my view) define DOTIMES so that it implies the
> behavior of IGNORE w/o having to explicitly say how they
> interact.
>
> Huh? Are you saying you'd define DOTIMES as if it included
> a (DECLARE (IGNORE I)) in your expansion? That it would therefore
> always warn? Or always warn if you use it? Surely I've failed
> to understand your point!
Consider an example, the definition of DO in CLtL II, pages 164-8,
and in particular the explanation in terms of BLOCK, LET, LOOP,
PSETQ, etc. on page 168. If I knew how IGNORE worked for those
constructs, I could infer it's workings for DO.
> This list isn't complete, but I think it demonstrates how easily
> these things can be specified, once the right framework is in place.
Given that the sort of solution I would prefer probably isn't going
to happen, I think your framework, etc. is the right way to go.
-- Jeff
∂03-Aug-90 0936 Common-Lisp-mailer DOTIMES
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 3 Aug 90 09:36:25 PDT
Received: from charon.MIT.EDU by MCC.COM with TCP/SMTP; Fri 3 Aug 90 11:08:34-CDT
Received: by charon.MIT.EDU
id AA02423; Fri, 3 Aug 90 12:08:17 EDT
Date: Fri, 3 Aug 90 12:08:17 EDT
From: kab@charon.MIT.EDU (Kim A. Barrett)
Message-Id: <9008031608.AA02423@charon.MIT.EDU>
To: RWK@FUJI.ILA.DIALNET.SYMBOLICS.COM
Cc: common-lisp@mcc.com, snicoud@atc.Boeing.COM
In-Reply-To: Robert W. Kerns's message of Thu, 2 Aug 90 19:04 EDT <19900802230414.8.RWK@KILIMANJARO.ILA.Dialnet.Symbolics.COM>
Subject: DOTIMES
<< Note: CC list cleaned up >>
> (DEFMETHOD YOW ((VAR MY-CLASS)) <here>) Referenced
>
> By the way, unless there's some specification language floating
> around somewhere that I've forgotten, the DEFMETHOD case above
> is another issue. I actually expected that the first DEFMETHOD
> case above would be Unreferenced, not Referenced. However, all
> implementations of CLOS that I've used implement the behaviour
> I documented above.
The 4th paragraph of the "Remarks" section of the function pages for DEFMETHOD
in 88-002R says
"The expansion of the DEFMETHOD macro ``refers to'' each specialized
parameter ... This means that a compiler warning does not occur if the body
of the method does not refer to a specialized parameter. ..."
∂03-Aug-90 0948 Common-Lisp-mailer Hash tables
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 3 Aug 90 09:48:39 PDT
Received: from charon.MIT.EDU by MCC.COM with TCP/SMTP; Fri 3 Aug 90 11:27:10-CDT
Received: by charon.MIT.EDU
id AA02458; Fri, 3 Aug 90 12:23:51 EDT
Date: Fri, 3 Aug 90 12:23:51 EDT
From: kab@charon.MIT.EDU (Kim A. Barrett)
Message-Id: <9008031623.AA02458@charon.MIT.EDU>
To: RWK@FUJI.ILA.Dialnet.Symbolics.COM
Cc: silbert@nadc.nadc.navy.mil, common-lisp@mcc.com
In-Reply-To: Robert W. Kerns's message of Thu, 2 Aug 90 15:17 EDT <19900802191744.5.RWK@KILIMANJARO.ILA.Dialnet.Symbolics.COM>
Subject: Hash tables
> In addition, there is a proposal in the works for a protocol
> to allow people to define additional test/hash combinations.
> (Kim Barret has spearheaded it; I don't remember who the other
> participants have been).
The status of this is that I've received extensive comments on an early draft.
My reading of these comments indicate that while such a portable interface can
be done, there are fundamental differences in the style of interface desired by
some of the reviewers, and these differences need to be ironed out. The plan
was to submit the design to Lisp Pointers as a technical article, and I still
intend to do so, though the schedule for completion has slipped considerably.